RPCE again

[Renegade]

read here for example: http://forums.renegadeprojects.com/showt...632&page=2 Post #13

Hey, look! One of the problems reported was the user's fault! That invalidates all other complaints!! </sarcasm>

thinks... because someone put not right information.

I am not talking about this single revision.

No. I update ModEnc too.

The help pages on ModEnc are half outdated, half junk. They're practically useless unless you invest half an hour to decrypt them, separate fact from fiction, and make sure they aren't outdated by now.

And why no one go and help me to copy information from RPCE help to ModEnc?

Because it'd mean supporting this tactic?

someone should join into RP team as help writer.

For that, you'd have to write down and release clear, precise information what which flag does and how it works.
...if you already wrote down clearly and precisely what a flag does and how it does that, there's no reason not to just save that text on ModEnc and be done with it - why would we need someone else to paraphrase what was precise and save it in an inaccessible and quickly outdated format?

And what is your ideas?

1. Feature Freeze. Create one bug-free version. Fix what's fixable, disable what's too buggy. Then declare that version a Base Version. Features present in a base version will not be changed anymore in any way, except if a total rewrite is necessary, and even if a total rewrite is necessary, the flag stays the same - that way, mods can code and rest assured "If people have Base Version 1, everything will work, and there won't be any RP-bugs.". That gives them the stability and safety needed to actively develop for RockPatch.
   
2. Use a simple, easy, widely accepted numbering scheme, and stay with it. Something like 1.08.0035 or something, or just names (like linux distributions use). Not shit like 1.10 Rev. #0042 Second Celebration Editions. Crap like that makes it hard to keep track which version is current, and which one you are using. Especially if the version number in the menu just says 1.10 or something.
   
3. Make all versions successors of the previous one. If you release version B, it should be the successor of version A, and the predecessor or version C. Nothing else. (Not like 1.08 SE, or CE, which are both successors of 1.08, but apparently not quite 1.09.) Don't get me wrong: There's nothing against bugfix releases. Just don't make them "real" versions. If 1.10 is fucked, release 1.10.0001 with bugfixes. And nothing else. Save new features and grave changes for 1.11.
   
4. Make available an internal beta, for tests with trusted beta-testers. These can be revisions, release candidates, alphas, betas, I don't care. As long as an independent reviewer had a look at how the patch performs before it gets released. (With a then-sane version number.)
   
5. Update ModEnc correctly and quickly. If you can't or won't, release correct, precise, current data to us directly (not through the offline crap) so we can do it.
   
6. Involve the coders of big RP-using mods, like AG, Speeder and Nighthawk in your planning. Actively ask them what they need. These are the people promoting RockPatch. If they don't like it, there's no need to continue coding.
   
7. Look at the votelist. The under-represented, non-big-mod modders made quite clear what they'd like to see. Give it to them, and they will be much happier and forgiving.
   
8. Look at the wishlist. If it's on the wishlist, at least one person would like to see it. If you only code what you want, people will view RockPatch as nothing more than "VK's mod" - and why would they actively help develop your mod if their own is waiting?
   
9. Update the goddamn bugtracker quickly, actively and precisely. That is the way people keep track of the progress of the bug they reported. How are they supposed to know whether Required/ForbiddenHouses works for custom countries if the bug has been open for almost eight months with no feedback from you? If it's fixed, mark it as such. If it's not fixed, don't just dismiss it. If you're not going to fix it, then mark it as "won't fix" and give a fucking reason. People can't read minds. They rely on the information you give them. If you don't give information, they can't rely on you, and if they can't rely on you, they won't plan with you - and that means not using RockPatch.
   
10. Listen. To. Us. It's like I said last post - if half the people complain, there is likely something wrong. Listen to what we say. Give reasons for your decisions. Be open. Accept the fact that you are not god and not infallible, and that what you like may be the biggest bullcrap ever seen for the rest of the community.
    I'm not trying to say you should quit implementing features you, personally, would like to see. I'm saying quit acting like your decisions are the almighty word of God and unchangeable. If half the people doesn't like an implementation, try to reach a compromise to make most of them happy.
    Same goes for for features. If you announce you'll spend your time working on particular, very obscure, never-previously-mentioned feature, and there's an outcry you should rather spend your time fixing bugs or implementing features that have been high on the votelist for months, then you should think about that argument instead of just deciding "No. I'll do ObscureRockPatchFeatNo55= now". Just balance it out. Half features for the community, half obscure features for you, and everybody will be happy.
    

So there. I've got a ten-point-plan to significantly improve the quality of both RockPatch and it's development cycles. You wanted my ideas, you have them. I am confident I have most others behind me on this one. It's your turn to act.

But don't think we'll miss the irony if you decide to not listen to us telling you to listen to us.