Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: General Battuta on April 23, 2012, 10:30:49 am
-
It is worth noting that you don't need to waste an entire persistent variable on a 0 or 1 flag bit. Thanks to the bitwise sexps, you can store up to 32 flags in a single variable. :)
Axem knows all about how to bitwise yo
e: Honestly, while I completely respect the triage on these feature requests, I think it's getting a bit dangerous that many of the SCP coders haven't stayed in touch with some of the more recent, more ambitious projects. Features have been implemented in the past 'just' for TBP or Diaspora or whatever, and while it's true that these projects have dedicated coders to make it work, I think it would be seductively easy to misapprehend exactly how significant of an achievement WoD represents -- and, from there, decide that 'just for WoD2' is somehow less significant.
And I know that the respect and appreciation of some of the oldest SCP architects would feel really valuable to the people who are pushing that engine.
-
(separate post since this may warrant splitting the thread)
Honestly, while I completely respect the triage on these feature requests, I think it's getting a bit dangerous that many of the SCP coders haven't stayed in touch with some of the more recent, more ambitious projects. Features have been implemented in the past 'just' for TBP or Diaspora or whatever, and while it's true that these projects have dedicated coders to make it work, I think it would be seductively easy to misapprehend exactly how significant of an achievement WoD represents -- and, from there, decide that 'just for WoD2' is somehow less significant.
And I know that the respect and appreciation of some of the oldest SCP architects would feel really valuable to the people who are pushing that engine.
That's a great perspective, and I know (from what others say, even if I haven't played it myself) that campaigns like WoD and Diaspora are really pushing the envelope of what can be done with SCP. And it is definitely true that both SCP and mods benefit from awesome features. There's plenty of honor to go around, and it is mutually rewarding for both teams.
But I'm looking at this from the opposite perspective. I'm concerned that SCP is currently in a feature bubble that is in dire need of deflation. I remember back around the time of SCP 3.5, people were tossing features into the codebase left and right, often with the specific and admitted objective of getting the code written whether it worked 100% or not. Eventually the codebase got so buggy and disorganized that people were trying to write features on top of other features, and changing stuff around regardless of whether it affected anything else. The result was a buggy, bloated, unstable mess. It took a lengthy, concerted effort by Taylor to squash all the bugs and re-engineer everything to be more stable, robust, and extensible.
Lots of natural processes go through the boom/bust cycle. You have the economic expand and contract cycle, the predator/prey ecological cycle, the cycle of growth, overgrowth, fire, and seedlings in forests, etc. It is useful for development to follow the same cycle: you add a bunch of cool features for a season, and then for a season you take a step back and make sure things are engineered correctly, make sure features aren't conflicting with other features, and refactor the things that it makes sense to refactor.
For quite some time now, bugfixing has gotten a lot less attention than it deserves. Coders are usually very concerned about making sure their feature is implemented, but how often do they trawl through Mantis and look for bugs that they know how to fix, or that they might be able to fix given a little bit of programmer growth?
I want to make clear that this post isn't directed specifically at WoD, or any poster here in particular. It's generally applicable to everybody in SCP, myself included. Furthermore, there are two very positive developments that distinguish today's development from the development of yore. First of all, coders frequently post "Code review" threads to get multiple sets of eyes on a given patch, with the result that the patch is better designed and better debugged than it would be with a single person working on it. Second of all, coders tend to stick around nowadays; we don't have people dumping 80%-completed features into the code tree and then disappearing for six months, without explaining their feature or providing debugging support for it. This happened a lot in previous years; I can think of three different coders who did this more than once.
But there are a lot of risks we're dealing with nowadays. Larger features are more likely to contain bugs than smaller ones. Complicated features are more likely to contain bugs than simple ones. Special-use features are used less frequently, have fewer pairs of eyes looking at them, and are therefore less likely to have their bugs detected than frequent-use features.
And many parts of the code need to be refactored -- from relatively simple cases like the asteroid code, to relatively complicated cases like subsystem rotation. And considering that refactoring is usually a long, difficult, and thankless job, it's not surprising that coders don't want to do it, or that coders don't do it very often. Not to pick on Valathil, but look at the reception he gets whenever he posts a crazy graphical test build in the public forum -- even a build based on code that isn't even in trunk. Compare that with the reception karajorma got for his brilliant re-engineering of the multiplayer sexp system. Few coders know about it; fewer still use it. And yet it's been instrumental in bringing order to the chaos that is multiplayer gameplay support.
We need to foster a culture that makes the code better, not just fuller-featured. Better includes fewer bugs, increased stability, better error messages, better documentation, and more elegant design. We need to have a system that satisfies the following three goals:
1) People who are less inclined to fix bugs should be more inclined to fix them
2) People who lack the knowledge or experience to fix bugs should be able to gain it
3) People who have historically been inclined to fix bugs AND have the appropriate knowledge to do so, should not be relied on to the point of getting burned out or having no time to work on stuff that they like
And I'm not sure how best to do that on a project like SCP, where people aren't getting paid to do the work and which tends to shun explicit organization in favor of self-motivation.
TLDR version: fix bugs, y'all.
-
I think that's a really good post, Goob, and I very much agree with the need for bugfixing and stability - BP has been hit hard by the 3.6.14 RC candidates and nobody on the team has put in the time to track down the exact problem.
At the same time, I just want to highlight two practical points:
1) The vast majority of the community's exciting, sexy, user-enticing new content generation is done by a small handful of people, all of whom generally need to make at least a couple feature requests in order to keep their projects ticking along.
2) A lot of these people wish that older members would play their campaigns, because the approval and respect of those older members is valuable to them. This isn't always practical (I've hardly played a new campaign since I got involved in development), but there have been a few cases where coders didn't understand why new features were valuable because they didn't have context to place them in.
-
And many parts of the code need to be refactored -- from relatively simple cases like the asteroid code, to relatively complicated cases like subsystem rotation. And considering that refactoring is usually a long, difficult, and thankless job, it's not surprising that coders don't want to do it, or that coders don't do it very often. Not to pick on Valathil, but look at the reception he gets whenever he posts a crazy graphical test build in the public forum -- even a build based on code that isn't even in trunk. Compare that with the reception karajorma got for his brilliant re-engineering of the multiplayer sexp system. Few coders know about it; fewer still use it. And yet it's been instrumental in bringing order to the chaos that is multiplayer gameplay support.
Indeed, that annoys me greatly since I went to the trouble of making the system easy enough that any coder should be able to use it and then went to the further trouble of posting an explanation on how to use it. But with the exception of CommanderDJ I don't think anyone else ever has and it usually ends up being me who has to fix broken SEXPs.
Fortunately, I'm not the sort of person to give up doing stuff like that just cause I'm not getting a ticker tape parade for doing it. :)
But yeah, I agree with the main sentiment that we need more people fixing bugs.
-
We need to foster a culture that makes the code better, not just fuller-featured. Better includes fewer bugs, increased stability, better error messages, better documentation, and more elegant design. We need to have a system that satisfies the following three goals:
Do performance optimizations count? I've been mostly focusing on those instead of features because I'd rather not have the engine running like ass if I implemented a pet feature in the game.
-
We need to foster a culture that makes the code better, not just fuller-featured. Better includes fewer bugs, increased stability, better error messages, better documentation, and more elegant design. We need to have a system that satisfies the following three goals:
Do performance optimizations count? I've been mostly focusing on those instead of features because I'd rather not have the engine running like ass if I implemented a pet feature in the game.
as a non coder :yes:
-
Do performance optimizations count? I've been mostly focusing on those instead of features because I'd rather not have the engine running like ass if I implemented a pet feature in the game.
Absolutely. In fact I'd say we've had an even harder time getting people to make performance optimizations than we have had trying to get them to fix bugs. As far as I remember, you're the only person other than Taylor and myself to have run profiling builds and committed fixes based on that data. And I never did it in a systematic way. I just grabbed a couple of low hanging fruit type bugs.
-
i kinda get the feeling that there is so much feature creep in the engine right now. i remember when you couldnt get a feature implemented if the entire community was screaming for it and several mod projects demanding it. nowadays it seems all you got to do is post a thread about an idea you had, and provided the idea was good enough, had enough people that wanted it, and the coders thought it was a good idea, you get a build a week later. thats kinda why i hopped on to the scripting system early on because i realized it would have the potential to implement some of the features the coders didnt really have the time for. even after we had scripting i noticed a lot of stuff that you can do with scripting was being implemented engine level. it was a major frustration for me, after spending time working with and even improving scripting by adding features to the system. seems like only now its starting to really pick up.
i kinda think features need to be as broad and far reaching as possible to get the most out of them. im not a big fan of the mod (or sf universe) specific feature, that can only be used in very specific cases. but i eventually got to a point where as a modder i couldn't keep up with new features fast enough. so yea im really thinking that the way we code features really needs to change. freespace by its nature is very easy to mod. and as a result it has brought in a lot of modders that have less diverse skill sets, as compared to other games that require some degree of code-fu to get anything done. this explains the slow uptake of scripting by the community, and i think this is another thing that needs to change. modders need to get their hands dirty and try out new skills, like lua or advanced sexps, or even c/++ for work in the engine.
-
I think that's a really good post, Goob, and I very much agree with the need for bugfixing and stability - BP has been hit hard by the 3.6.14 RC candidates and nobody on the team has put in the time to track down the exact problem.
Battuta, would you PM me on those issues?
-
Nuke, the new AI developed for Diaspora and BP has applications in every mod. Features like tactical jumps and SSMs are broadly applicable. Capship countermeasures are useful wherever there's a capship.
I think you should play some recently released content before you speak to decisions that could handicap mods in production.
-
Exactly. Although I'd like to see more usage of the Hosted Collaboration forum when dealing with features that mods want so that we can make sure features are useful to a broader range of mods rather than adding a feature Diaspora wants and then having to have BP change it to add the stuff they want from it, etc.
And I'm not saying this from the point of view of someone who has always done it. Given that we have nearly half the SCP on the Diaspora team we're more guilty than anyone of not doing this.
-
Nuke, the new AI developed for Diaspora and BP has applications in every mod. Features like tactical jumps and SSMs are broadly applicable. Capship countermeasures are useful wherever there's a capship.
I think you should play some recently released content before you speak to decisions that could handicap mods in production.
yea but those ARE examples of broad features. i was actually thinking of older features which have specific launcher flags :D
i am far passed my modding prime. im not really up to snuff on the latest and greatest offerings from current top tier mods. really those opinions were formed years ago, not by anything current.
-
Aren't most of those gone from the engine? Stuff like -tbp for instance?
-
like i said im not really up to snuff with the state of things. im not really an active modder either. electronics projects have taken over my spare time (though i have done some freespace <-> arduino interfacing demonstrations if anyone is interested in building a simulator). i never functioned well in a mod team, and the workload is much bigger than it used to be. so the days of the one man mod are pretty much over.
-
like i said im not really up to snuff with the state of things. im not really an active modder either. i never functioned well in a mod team, and the workload is much bigger than it used to be. so the days of the one man mod are pretty much over.
No, they aren't. The single biggest, most ambitious total conversion completed to date (Wings of Dawn) is a very recent release and done entirely by one man.
e: Vassago's Dirge and JAD 2.22, both incredibly technically ambitious, were done by one man. Blue Planet the first was done by one man
Nearly everything of significance outside Diaspora and WiH has been done by one man
-
i kinda get the feeling that there is so much feature creep in the engine right now. i remember when you couldnt get a feature implemented if the entire community was screaming for it and several mod projects demanding it. nowadays it seems all you got to do is post a thread about an idea you had, and provided the idea was good enough, had enough people that wanted it, and the coders thought it was a good idea, you get a build a week later. thats kinda why i hopped on to the scripting system early on because i realized it would have the potential to implement some of the features the coders didnt really have the time for. even after we had scripting i noticed a lot of stuff that you can do with scripting was being implemented engine level. it was a major frustration for me, after spending time working with and even improving scripting by adding features to the system. seems like only now its starting to really pick up.
i kinda think features need to be as broad and far reaching as possible to get the most out of them. im not a big fan of the mod (or sf universe) specific feature, that can only be used in very specific cases. but i eventually got to a point where as a modder i couldn't keep up with new features fast enough. so yea im really thinking that the way we code features really needs to change. freespace by its nature is very easy to mod. and as a result it has brought in a lot of modders that have less diverse skill sets, as compared to other games that require some degree of code-fu to get anything done. this explains the slow uptake of scripting by the community, and i think this is another thing that needs to change. modders need to get their hands dirty and try out new skills, like lua or advanced sexps, or even c/++ for work in the engine.
I agree with this sentiment but I feel as though the mod/universe specific feature problem hasn't been really been a huge issue as of late. I suspect the only thing the Diaspora team has been guilty of is the inclusion of DRADIS mode radar but that so far has been treated like any other HUD gauge since I finished the HUD rewrite. Thing is that Freespace has been hardcoded from the outset and most features requests has been asking for simply more control over these features. A lot of features have been written with a data driven philosophy in mind with plenty of broad applicability even if the requester has a specific application in mind.
And yes, launcher flags should go to hell. Features should be granularly controlled and flexible. A fail example of this is the JAVELIN weapon flag. Why not have coded it to be something like "Subsystem Exclude List" or "Subsystem Include List" while having an option for whether it can lock while being occluded or not? It's really that simple to break it down.
-
i kinda think features need to be as broad and far reaching as possible to get the most out of them. im not a big fan of the mod (or sf universe) specific feature
I kinda think you need to stop talking. I'd hate for actual coders to be even remotely influenced by this train of thought.
This is what you sound like to me "I don't actually play or mod anything, but I think it's better for all those mods that are in production and reliant on the implentation of certain features to be completely stalled because I have the vague impression that the code is being 'inflated' by all these new things."
If you are not actually going to participate in a meaningful way in the mod scene, don't go and try to backseat code or backseat moderate on what you think the SCP should be doing,
kthx
-
It's like Nuke exists in a tangent universe where BWO and Inferno and Scroll actually came out, and the mod scene wasn't instead completely dominated by one-man projects (and Diaspora, and TBP I guess) while most of the team-based mods rotted away.
-
like i said im not really up to snuff with the state of things. im not really an active modder either. i never functioned well in a mod team, and the workload is much bigger than it used to be. so the days of the one man mod are pretty much over.
No, they aren't. The single biggest, most ambitious total conversion completed to date (Wings of Dawn) is a very recent release and done entirely by one man.
e: Vassago's Dirge and JAD 2.22, both incredibly technically ambitious, were done by one man. Blue Planet the first was done by one man
Nearly everything of significance outside Diaspora and WiH has been done by one man
well for me they are. i created so much material early on before scp and htl came into play. bringing that into the current era has sapped most of my enthusiasm for modding.
-
Aren't most of those gone from the engine? Stuff like -tbp for instance?
Indeed they are. Nuke is stuck about 2 years ago it seems.
The culture of the SCP team has changed (for the better I think) to one that is much less mod specific focused, which was what actually sparked this split from its original thread in HPC.
If you are not actually going to participate in a meaningful way in the mod scene, don't go and try to backseat code or backseat moderate on what you think the SCP should be doing,
kthx
Careful Spoon. This is a public forum and Nuke is entitled to his opinion. He is also not a member of HPC so he doesn't know that this split was actually a result of a mod maker objecting to his exact position by a SCP member.
-
i kinda think features need to be as broad and far reaching as possible to get the most out of them. im not a big fan of the mod (or sf universe) specific feature
I kinda think you need to stop talking. I'd hate for actual coders to be even remotely influenced by this train of thought.
This is what you sound like to me "I don't actually play or mod anything, but I think it's better for all those mods that are in production and reliant on the implentation of certain features to be completely stalled because I have the vague impression that the code is being 'inflated' by all these new things."
If you are not actually going to participate in a meaningful way in the mod scene, don't go and try to backseat code or backseat moderate on what you think the SCP should be doing,
kthx
im not pointing any fingers. everyone seems to assume i am. i was merely stating what i think is an optimal feature design paradigm. as a modder i may be retired, but i have added several features to the engine, not to mention all the work ive done with scripting (including new features). surely my examples have inspired others.
-
Everyone assumes you are out of touch, something you actually seem to confirm yourself.
When you start to promote 'an optimal feature design paradigm' that would screw mods over I get grumpy. At least make an effort to be up to date with the scene before doing these meaningless suggestions.
-
i am out of touch, i admit. but i'm not looking to "screw over mods" as much as i am at improving the engine. frankly i dont see what could be so threatening about a paradigm that encourages broad, far reaching features that are highly configurable and not universe specific (in that they should be configurable enough to fit any universe or gameplay style the modder requires). how is that threatening? how does that "screw mods over"? i dont see what youre freaking out about. im certainly not talking about deprecating existing features (even though in some cases it might be a good idea).
-
Do you have any recent features in mind that you feel are too universe-specific?
-
recent? no. though for awhile i was convinced that diaspora was intentionally crippling the script side rtt with their dradis gauge (i had rtt radar gauges back in 2008 btw, and i made those scripts available on my svn over at fs mods). this just turned out to be a bug though, so my paranoid delusions were completely unjustified. :D
-
"Better prevent this mod do this really cool thing with this one feature, It's 'too universe specific'! Can't have it clog up the engine!"
-
"Better prevent this mod do this really cool thing with this one feature, It's 'too universe specific'! Can't have it clog up the engine!"
How many features went into the engine for, say, BWO? Or any other project that has since submerged and died? I can't say offhand but I know there have been some. That work is essentially wasted if it's not useful to everyone.
-
I don't know, you tell me!
If anything, I think more features have gone to waste because of poor documentation in the wiki than anything else.
-
I've thought about saying something about updates on the wiki before, but I feel like there are more important priorities.
Features can also be documented via tutorials. It might be more productive to not only show how someone how to do something but also to do it with new features at the same time.
For instance, writing a tutorial on the various uses of the AI_profiles table would do just as much, if not more than updating the wiki would and would provide a way for a lesser members of the community to update the wiki themselves. (although someone needs to know the information first, I suppose)
That's how I found out about bit-editing sexps for variables. (Although that came out in the discussion afterward.)
-
Actually, a lot of the arguments with WCS were because of features they wanted that we requested to be implemented in a more generic, useful fashion instead of a very narrow, hackish, and probably retail-breaking manner that they were proposed. Just some food for thought.
-
Um no. Some people already don't even put basic documentation on the Wiki, and you want them to instead write a whole tutorial? That seems like a pipe dream. Simple documentation of new features on the Wiki is all that's needed. Anything more than that is bonus.
However, this isn't a thread about Wiki documentation. Nor is it about Nuke being out of touch with the current modding reality at HLP. This here thread is about too many features and not enough bugfixes and optimizations.
My simple two cents is this. If everyone followed the code cycle properly then this would be less of an issue. I'm as much to blame as anyone else on this actually. But I figure if coders straight up didn't work on features during RC and modders stopped asking for features during RC, then we might see more bugs being fixed. We also might not find ourselves lost in a 5 month RC period...
Yes, I know not asking for features during an RC phase seems like a lot to ask, especially for bleeding edge mods looking to push the boundaries further. However, this is a community project and no one gets paid for it... Gotta be patient do our part in order for a better codebase in the long run. Hopefully I've communicated that clearly considering the time and lack of sleep.
-
Actually, a lot of the arguments with WCS were because of features they wanted that we requested to be implemented in a more generic, useful fashion instead of a very narrow, hackish, and probably retail-breaking manner that they were proposed. Just some food for thought.
Exactly. They were pretty much the only mod that did ask for features that only worked for them. I don't think it's a coincidence that the exact feature that Swifty singled out was one of those.
-
most of the initial wiki documentation is adequate. sometimes you need to clarify. if a modder finds a description in the wiki vague or insufficient, they should feel free to fix the description. perhaps it would be a good idea for coders to start putting their names on their features in the wiki in cases where documentation is so poor its useless, so that the feature coder(s) can be contacted and the wiki clarified. i put up basic documentation for all my non-scripting features. the scripting features are somewhat self documenting through scripting.html, though i think we need to come up with some better scripting documentation. scripting.html is good for a function reference but really doesnt do much to explain hooks or hook variables and the like. dont need to document lua, or the built in libraries, as there are plenty of tutorials for that. information about how to put the freespace specific libraries to work is somewhat lacking.
im not really a big fan of tutorials. most of the time its 'look what i can do! heres the code! im not gonna tell you how or why it works!'. tutorials are also too specific to a topic. your better of explaining theory of operation, paradigms and conventions with nice little flowcharts explaining how stuff works. explaining basics like timing, working with files (in the engine's context), talking with missions, operating on built-in (userdata) structures, how to write easy to debug code.
-
But I figure if coders straight up didn't work on features during RC and modders stopped asking for features during RC, then we might see more bugs being fixed. We also might not find ourselves lost in a 5 month RC period...
Thing is, I don't think a lot of projects care much about RC right now.
JAD 2.21 released without waiting for a .14 final build because it took too long and JAD was already completed by then.
Dimensional Eclipse released without waiting for a .14 final build because the mod requires a build that supports a certain armor.tbl feature that is not included in the RC cycle
WoD2 doesn't work with RC builds because of a few features that are only present in newer builds.
I don't know for sure about Diaspora&BPr2, but I have the vague impression that both of these probably require other builds too.
.12 final fell nicely together with the release of 3 campaigns on the other hand.
-
im not really a big fan of tutorials. most of the time its 'look what i can do! heres the code! im not gonna tell you how or why it works!'. tutorials are also too specific to a topic. your better of explaining theory of operation, paradigms and conventions with nice little flowcharts explaining how stuff works. explaining basics like timing, working with files (in the engine's context), talking with missions, operating on built-in (userdata) structures, how to write easy to debug code.
Yup, Axem's tutorials on his various topics are aweful. People should just look up the documentation on conditional argument sexps instead... I'm sorry Nuke, but sometimes you come off as a negative nancy with all the things you don't like/aren't a fan of/think aren't worth it. My guess is that you probably never looked at Axem's tuts or some of the other tuts around (like mine on Anim creation) in a long, long time. And so once again you might be making grand assumptions about an area of HLP modding that you are too far removed from.
But I figure if coders straight up didn't work on features during RC and modders stopped asking for features during RC, then we might see more bugs being fixed. We also might not find ourselves lost in a 5 month RC period...
Thing is, I don't think a lot of projects care much about RC right now.
JAD 2.21 released without waiting for a .14 final build because it took too long and JAD was already completed by then.
Dimensional Eclipse released without waiting for a .14 final build because the mod requires a build that supports a certain armor.tbl feature that is not included in the RC cycle
WoD2 doesn't work with RC builds because of a few features that are only present in newer builds.
I don't know for sure about Diaspora&BPr2, but I have the vague impression that both of these probably require other builds too.
.12 final fell nicely together with the release of 3 campaigns on the other hand.
Indeed that is true, but I'm also curious how many features were being added to trunk during the 3.6.12 RC cycle. I'm honestly curious because I can't remember. I also wonder if more mods would have cared about 3.6.14 if the bugs were focused on and RC finished up in a timely fashion like 3.6.12 did.
-
Indeed that is true, but I'm also curious how many features were being added to trunk during the 3.6.12 RC cycle. I'm honestly curious because I can't remember. I also wonder if more mods would have cared about 3.6.14 if the bugs were focused on and RC finished up in a timely fashion like 3.6.12 did.
The reason that so many features have been added during the RC cycle is that this RC cycle took far too long. SCP is currently trying to crack down and get .14 out. We don't prevent commits to trunk during RC primarily (I assume anyway) because the RC process is not supposed to take more than about 1 month, so trunk doesn't really get much chance to get away from the RC.
-
Actually we've avoided putting in a lot of 'features' into the RC. A lot of features have made it into trunk during the RC phase, but a lot of them have been shut out of 3.6.14.
-
Actually we've avoided putting in a lot of 'features' into the RC. A lot of features have made it into trunk during the RC phase, but a lot of them have been shut out of 3.6.14.
I thought that was the point of an RC? To stop putting features in and shake out the bugs.
-
Which kind of breaks down in the face of RC phases that take several months.
-
Yup, this one is taking longer than I had hoped, as usual. We've hit quite a few nasty bugs this time around though, probably due in part to the low amount of bugfixing that went on during the feature commit phase. That's why Goober has been pushing so hard for measures to enforce bugfixing by all members, and why I'm being more and more inclined to agree to some of the ideas we've discussed. Unless we can get some better ideas.
-
i like how spoon brings up those armor.tbl features, ya know, the ones that i wrote :D
im not really a big fan of tutorials. most of the time its 'look what i can do! heres the code! im not gonna tell you how or why it works!'. tutorials are also too specific to a topic. your better of explaining theory of operation, paradigms and conventions with nice little flowcharts explaining how stuff works. explaining basics like timing, working with files (in the engine's context), talking with missions, operating on built-in (userdata) structures, how to write easy to debug code.
Yup, Axem's tutorials on his various topics are aweful. People should just look up the documentation on conditional argument sexps instead... I'm sorry Nuke, but sometimes you come off as a negative nancy with all the things you don't like/aren't a fan of/think aren't worth it. My guess is that you probably never looked at Axem's tuts or some of the other tuts around (like mine on Anim creation) in a long, long time. And so once again you might be making grand assumptions about an area of HLP modding that you are too far removed from.
wtf is with all this anti nuke bs on this thread. im starting to get rather sick of it. stop acting like i havent done anything for the community and im just some kind of parasite on hlp. i just stated my opinion of tutorials. there needs to be a balance between tutorials: "how do i implement x", function/sexp/tag references (specific detail about what each little thing does), so far the latter has been most useful to me over the years. but there is a total lack of general theory of how everything is supposed to play together. my problem with tutorials is that they are merely too specific.
-
I appreciate your addition to the pspew code, allowing for cool particle trails, nuke.
I think the reactions you are getting here mostly comes from your posting behavior that frequently involves coming to a thread, making long posts about: 'This is how nuke would have done it, had he made the feature himself' or 'Back in the day, I already made this in nukemod.' but then you don't actually cough up any relevant code. You just let everyone know that you could have done it, or have already done it in some incomplete way and then leave the thread. Adding nothing of value.
And now in this thread, again you deem it fit to tell everyone 'this is how *I* would regulate the codebase' even though you have no real stake in this, considering you don't mod anything anymore.
-
Why did you get out of modding again, Nuke? You stated the reason recently, but I'm not sure it still holds validity. If it doesn't, well then, take back your cloak, mage!! C'mon, you know you want to...
-
scripting for one. most of the modding ive done lately has revolved around script development. and electronics projects have eaten a lot of my time. i still kinda want to finish existing mods, and revamp my older models. but i think my inner engineer and inner coder has stomped my inner artist to death.
-
Now that I've had some time to think about this issue after having been out of town, I wanted to add some things to the discussion, since I think this is a really important topic.
First, about the bug fixing issue that Goober brought up early in the thread, I think the best way to remedy it is to create a culture in SCP where it's expected that the obligation to fix bugs comes with the privilege of being able to submit/commit patches for new features, with the understanding that some bugs require substantially more work to fix than others and that should be taken into account when considering how much bug fixing qualifies as "enough." Furthermore, I'd think it's appropriate that the more features a coder wants to add, taking into account the total complexity that those features would add, the more work they should be expected to put into bug fixing/refactoring.
Second, requests that are targeted to benefit just one mod, with no clear application to other mods in progress or reasonably plausible scenarios for future mods, are likely to be a hard sell, not just for coder time spent on implementing them but also for getting patches for them accepted, for the reasons Goober mentioned earlier in this thread. That's not to say that they shouldn't be considered, though, simply that they're a hard sell. This comment isn't targeted towards WoD or any other specific mod or specific feature but is just meant as a general statement.
To qualify my response and perhaps even discount it a bit, I don't work on FSO, so I have a bit of an outsider perspective. That said, for the hundreds of hours that I have put into wxLauncher so far, I have added just two features, one that's substantial but not that large, and one that's very small. Nearly all of the time I've spent on it has gone into OS X support, UI revisions, or bug fixing/refactoring. Future work on wxL for at least the foreseeable future will go into more bug fixing/refactoring or into adding features that are obviously useful (like a refresh button for the list of mods) or absolutely necessary (like support for the new sound code).
Anticipating some probable replies given the first page of this thread, I'll say that my opinion is just that -- my opinion! Other SCP members may feel differently, and it's likely that at least some of those who do will post here.
-
Several SCP members have stated a desire to going over to a system whereby you must provide a certain number of bug fixes before you can add a feature. The numbers quoted were something like 5 to 1 with bugs in your own features not counting (quite frankly you should be solving those without having to be asked!).
The 5 to 1 number was simply meaning to point out that 5 simple bug fixes were worth one feature. The number would go up or down depending on the difficulty of the bug fix, etc.
-
Out of curiosity, where would refactoring come into this? Say, going through a source file and making some sort of memory optimisation? Would that count as more of a bug fix or a feature?
-
Bug Fix. Definitely.
In fact it would probably count as several bug fixes.
-
The only issue there is that almost any major refactor is going to generate its own share of bugs once it hits broader testing. A lot of our 'features' have been the result of a massive refactoring/upgrading of a chunk of code. go_faster, HUD, OpenAL upgrade, and look at the number of bugs introduced by each of those.
-
I personally didn't have anything major in mind, I was more thinking along the lines of simply swapping data structure types, changing unneeded ints to unsigneds, that sort of thing. Minor stuff. But I get what you're saying.
-
The only issue there is that almost any major refactor is going to generate its own share of bugs once it hits broader testing. A lot of our 'features' have been the result of a massive refactoring/upgrading of a chunk of code. go_faster, HUD, OpenAL upgrade, and look at the number of bugs introduced by each of those.
This makes me wonder if we have the same definition of "refactoring." When Goober mentioned it on the first page of this thread (quote below), I understood it to be restructuring a component of the engine for improved readability and maintainability, more elegant design, or to fix some bugs that can't be fixed otherwise because the structure of the existing code makes fixing them impossible or infeasible. This definition fits with karajorma's rewrite of the multi sexp system, and it's the definition I had in mind in my post.
Thus I'm confused as to how a refactoring could generate a bunch of additional bugs, assuming it's done carefully. Were the bugs a result of just the upgrade aspect, or also the refactoring itself?
And many parts of the code need to be refactored -- from relatively simple cases like the asteroid code, to relatively complicated cases like subsystem rotation. And considering that refactoring is usually a long, difficult, and thankless job, it's not surprising that coders don't want to do it, or that coders don't do it very often.
-
Basically Chief meant that those refactorings were so large that they inevitably introduced bugs of their own. The new pilot code for instance was about 10,000 lines. Not much you can do about that having bugs really. You just have to roll up your sleeves and squash them.
As for the multiplayer SEXP system, I didn't refactor it. There quite simply wasn't one until I wrote one from scratch. The few SEXPs that did have an effect in multiplayer had their own special packets to send the changes in. So I could that as a massive bug fix/new feature rather than a refactoring. :D
The only issue there is that almost any major refactor is going to generate its own share of bugs once it hits broader testing. A lot of our 'features' have been the result of a massive refactoring/upgrading of a chunk of code. go_faster, HUD, OpenAL upgrade, and look at the number of bugs introduced by each of those.
Yes but again we get back to the point I made that we need to make it a point of honour to fix the bugs you introduce.
I know I've always felt that way. I'm quite proud of the fact I can say that as far as I know there are no bugs in any of the code I've written. That's not to say there aren't any, just that I don't know of any and if my code introduces them or I even suspect my code might have introduced them, I investigate them at top priority.
Now I'm not going to say anyone presently in the SCP doesn't do the same, but in the past, we really have had a big issue with people dumping code and then believing it's someone else's responsibility to fix it.
-
Yes but again we get back to the point I made that we need to make it a point of honour to fix the bugs you introduce.
I know I've always felt that way. I'm quite proud of the fact I can say that as far as I know there are no bugs in any of the code I've written. That's not to say there aren't any, just that I don't know of any and if my code introduces them or I even suspect my code might have introduced them, I investigate them at top priority.
Perhaps it would be a good idea to put this in writing, in the code base (a contributing file), and on the web pages where we talk about how to contribute to FSO.
Now I'm not going to say anyone presently in the SCP doesn't do the same, but in the past, we really have had a big issue with people dumping code and then believing it's someone else's responsibility to fix it.
Isn't that what antipodes is for?
(Obviously though, antipodes will never get a wide of testing as the nightlies or the release builds do)
-
In most cases with antipodes, the person writing the code has stuck around to fix the bugs. About the only one who didn't is Taylor and quite frankly until anyone else has 500 bug fixes in Mantis, anyone who is going to complain about that can shut their damn fool mouth. :p
This is unlike the bad old days when people would dump code into the repository and then wander off to do other things. I've lost count of the number of times I've had to fix bugs in code even though before I started working I could tell you who was to blame for.