• If people complain, there's likely an issue. Whether you agree it is an issue doesn't matter if half your userbase thinks it's an issue.
  
• There are still a whole shitload of old issues open in the bugtracker
  
• Many bugs and complains could have been avoided hadn't you decided to rename flags just for fun
  
• We couldn't help you write your documents, because
  
  1. You fell back to last century's offline help format, instead of using the already prepared RockPatch Docs part of ModEnc, and
     
  2. You have a tendency to reveal your changes after you released them upon us
     
• Quit acting like this is new. We complained about your attitude towards testing, your naming scheme, your stubborness all before. Quit pretending this is all a reaction to CE. We are unhappy with the general way this project is going, not just with this particular release.
  

Quote:I uploaded RPCE Help Update 5, which included Map SnapShot tutorial.

Renegade Wrote:[*]Many bugs and complains could have been avoided hadn't you decided to rename flags just for fun

Quote:Oh and then...I call Bullshit. "Don't believe the stupid posts about bugs, test it yourself!"?? That's got to be the most ridiculous cop-out I've heard in a long, long time. It's akin to "if I don't see it, it doesn't exist".

Quote:If people complain, there's likely an issue. Whether you agree it is an issue doesn't matter if half your userbase thinks it's an issue.

Quote:Help update 5...? The download able version is at 8... Is 5 the site? and so could you make it download able, i like being able to not have to get on-line to look at the help docs.

Quote:You fell back to last century's offline help format, instead of using the already prepared RockPatch Docs part of ModEnc, and

Quote:You have a tendency to reveal your changes after you released them upon us

Quote:Quit acting like this is new. We complained about your attitude towards testing, your naming scheme, your stubborness all before. Quit pretending this is all a reaction to CE. We are unhappy with the general way this project is going, not just with this particular release.

CnCVK Wrote:read here for example: http://forums.renegadeprojects.com/showthread.php?tid=632&page=2 Post #13

CnCVK Wrote:thinks... because someone put not right information.

CnCVK Wrote:No. I update ModEnc too.

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

CnCVK Wrote:someone should join into RP team as help writer.

CnCVK Wrote: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.
    

Renegade Wrote: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.

Renegade Wrote:I am generally talking about wanted vs. unwanted features. A feature may be as useful as ever for the one using it - if nobody uses it, 'cause nobody wants it, its implementation is a waste of time.