Posted: Sun Mar 31, 2013 1:20 am Post subject:
Branch fusion request... custom missiles and attacheffect
Both my mod projects (RA2:Ascension and RA2/3:Evolution) require both multiple custom V3 missiles AND the attacheffect. However these are in different ares testing branches.
I don't care how unstable it is, since there will be 0.3 released anyways, eventually, and by then the mods can be updated with it. This is just for developing purposes... I need V3-like custom missiles which can induce an AttachEffect.
Pleeeease? (?) It's just a fusion of already existing code, and would have to be done anyways sooner or later... _________________
AttachEffect has bugs with Crates. Merges are only done when certain features have been fully tested to be bug free... _________________ ~ Excelsior ~ QUICK_EDIT
Both branches are seen as "unstable" and "not ready", by separate, what damage can be done by just compiling a merger? It woudn't have to be marketed as usable, they are "unstable builds" for something...
Some people like me would want to just be able to use both functions for mod developing. Crates also can be temporarily disabled if so is needed...
(that I know of, the 0.3 prototype has neither? But perhaps Iam wrong, but it is not included on the features AAIK) _________________
Both branches are seen as "unstable" and "not ready", by separate, what damage can be done by just compiling a merger? It woudn't have to be marketed as usable, they are "unstable builds" for something...
Some people like me would want to just be able to use both functions for mod developing. Crates also can be temporarily disabled if so is needed...
(that I know of, the 0.3 prototype has neither? But perhaps Iam wrong, but it is not included on the features AAIK)
Because if you did this everyone else would want custom merged builds as well and that would hamper the progress on finishing up final builds. And since only AlexB (And Graion Dilach?) seem to be the only ones capable of doing merges... _________________ ~ Excelsior ~ QUICK_EDIT
A merge is not that much of a "hampering", I guess it's just copy the working from one to the other and compiling (heck, I can do the compiling provided with the source )... seeing as not many people would need more than this merge (nobody seems to have asked anything of the sort until now, and I don't see it happening, since most modders just work with the finished versions)
, and new versions take months, waiting that much can possibly hinder many things in mods, a lot more than the (presumably?) little work in merging them... anyways, in that case let them answer. _________________
You could, of course, just use both testing branches to test both branches, report all issues with them, and then use the inevitably appearing development snapshot with those features merged. _________________ #renproj:renegadeprojects.com via Matrix - direct link QUICK_EDIT
I cannot use them both at once, that is the point, and I cannot continue development into key points much further without them (missiles with attacheffects warheads is a feature I need for other mechanics, like upgrades, area effects, chemical strikes, a desolator version, custom ICBMs, Dreadnugh Abilities, V4 fragmentation and normal, etc. etc.). And it could take months before they are merged "after" debugging. I could report the bugs from the merged version. Why would you be against this? _________________
Because the fact that you cannot use both at once does not prevent you from using both testing branches to test both branches in order to clear the way for their merge into the master branch.
You want something. It's very easy to get: Just establish the right conditions. That takes a bit of work. Tough luck. If you're not even willing to work to get exactly what you need for your own mod, why would somebody else sit down and invest time and work for it? _________________ #renproj:renegadeprojects.com via Matrix - direct link QUICK_EDIT
. . .
I will work for it, I just can't do what I need right now. I don't need the bug-free branches. I just need them as they are but merged for prototype purposes.
Hell, even if they release the source codes of the separate branches or direct me to it, I can merge them myself...
why are people here so anti-other's requests? It's not as if you are the ones that will do it or need it.
It's not "very easy" to debug all things (particularly as, even if I report them, it's not up to me to resolve those bugs since I have no knowledge of RA2 .exe hacking), and I don't need them debugged. I CANNOT test them properly on my mod while not fusioned them.
I will submit bug reports from the fused version that will include at once:
- Bugs from attacheffect
- Bugs from Custom Missiles
- Bugs from the interaction of both those things.
It's actually x3 work, even if it's not the most "methodic" approach. _________________
Bugs are best tested one feature at a time, adding more complicates and burdens the developer far more. Each feature should be checked in various and methodical ways for each process via process of elimination until it's considered working.
If you want to work with both "prototype" unstable codes at the same time, any normal developer wouldn't even have bothered to respond to you. Ares developers did because their a friendly tolerant people, so please consider their points before starting an argument.
If you go and test each new feature by itself in various ways, "These ways must likely don't cater to your mod but this feature is for the community at whole not just your mod" and can't produce bugs with that experimental feature, and create a log of such testing. Then the developers will see it has been properly tested, and at that point, add it to the main testing branch, you can then try them together after that.
Of course they could just merge the branches together for you then your friends, then your Friends friends, and at the end of it there would be a hundred more unneeded testing branches, each with their own bug reports causing chaos. People at this point might abandon the bug testing all together since they think they got all the features they want with custom merged branches. I still agree with AlexB that unstable releases should have just been used for testing and not mod releases and creation. But open source testing does allow hopefully for more bug reports.
A request for them to not be methodical or smart about how they develop a free patch in their own free time, is like telling the community, I don't care what happens to the patch, so long as I can get the special treatment of my own custom branch for testing my mod's new uber stuff.
Not that I think you meant any harm or even understand what havoc you might be causing by asking for special treatment, but that's the most likely reason your so fervently being denied here. Any ARES developer feel free to correct me if I'm misinformed or misunderstanding your development strategies. _________________ Grab my Map Logic Expansion Pack 5.2 here!
Adds random weather patterns into maps.
More disabled navalyards.
Preplaced Neutral buildings.
Additional new features.
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Sun Mar 31, 2013 10:46 am Post subject:
You're totally right, Eric.
NimoStar, there won't be any such branches soon I think. I had made exceptions back then and it proved to be a bad idea. Alex doesn't even do exceptions.
No special treatments. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
I had written a response to this thread on sunday, but then my laptop failed and it was lost. I wasn't motivated to write it all again.
Creating more branches is creating a lot of work, because they might have to be maintained and updated whenever any of the parent branches gets updated, and even if it is a one-shot branch, I still have to keep the debug data because otherwise memory dumps would be unreadable and bug reports would not be that helpful. More branches mean more file juggling and generally just more overhead, which shifts the focus more to managing files. This distracts me from coding.
In the last months I have been changing the same old features over and over again. Some were verified as working and yet they failed when used in real life situations. They were changed again and tested successfully, yet again they later failed. Doing this five times for a stupid feature is not what I want to do. (It was only one feature that required 5 changes, but this really was enough for me.) Thus, only if features are fully tested, I'll release the source code and they can be merged into other branches. Otherwise I would still be accountable for bugs in features I finished months ago, and I really do not want to revisit these all the time because at some point I make my peace with them and move on.
In January I planned for a shorter release cycle and I really had hoped for a release back in Fabruary. Then the MO team experienced some severe bugs, disconnects and crashes. They do not appear to happen any more, but releasing was out of the question. For the last six weeks I have just been waiting for the remaining issues to be verified as working. One could argue that the Dropship Loadout issue could be removed because the feature is generally not finished. The White Color RE can't be verified with certainty (though it could be confirmed as "not working"), so it will be assumed to be working after it hasn't happened for some time. That would leave only three issues that still require some testing.
This is the testers turn, not mine. I'll not compensate testing that doesn't happen by doing more work. I'll just wait for other people to finish their part. Remember: It's just 14 issues in the trimmed down Ares 0.3. If I had continued to include all the features I already coded, it would never be released. Adding more features to a branch would just increase the number of untested features, and thus take us farther away from a release.
There are two ways to resolve this: Get Attach Effects branch fully tested so it can be merged into Ares 0.3 or get the Ares 0.3 branch tested so it can be merged into Attach Effects. Both would yield a binary that supports both feature sets.
Thanks to all the people who help testing! _________________ QUICK_EDIT
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum