[Nuke]

i like how spoon brings up those armor.tbl features, ya know, the ones that i wrote

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.

[Spoon]

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.

[jr2]

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...

[Nuke]

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.

[jg18]

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.

[karajorma]

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.

[CommanderDJ]

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?

[karajorma]

Bug Fix. Definitely.

In fact it would probably count as several bug fixes.

[chief1983]

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.

[CommanderDJ]

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.

[jg18]

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.

[karajorma]

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.

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.

[Iss Mneur]

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)

[karajorma]

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.

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.