Jump to content

EvilJackCarver

Members
  • Content Count

    720
  • Joined

  • Last visited


Reputation Activity

  1. Like
    EvilJackCarver got a reaction from Original Light in [GUIDE] Getting useful Solutions to your Problems   
    Notes for modstaff in spoiler.
    Preface
    This text was adapted from a document by Eric S. Raymond, titled How to Ask Questions the Smart Way. The full document is available here - the authors of this document are in no way affiliated with G17 Media nor myself, and aren't there to answer your questions about how to get whatever it is you're trying to get working, working.
    Introduction
    If you're reading this, hi there. I suck at smalltalk and making things sound nice, so I'll open with this: In the world of diagnostics, there are a few right ways to get Solutions... and many, many wrong ways. This post is here to hopefully help nudge you toward the right ways, so that you can get the Solutions you want easier.
    Of course, getting a good Solution isn't just on the people helping you solve your Problems - and you're naïve if you think that. A lot of the work needed to solve a Problem falls on you. A vast majority of the time, whether the issue gets solved depends not on the Problem itself, rather what the end user did to troubleshoot and what information they posted in their support threads.
    Depending on how you present your issue and what it may or may not contain, your Problem's thread may get zero replies, or a hundred; it may be solved in an hour, a week, or it may remain an unsolved mystery. This post is here to reduce the odds of that last bit.
    Still with me? Let's begin.
    Before you post:
    Reproduce the issue.
    Try to reproduce the Problem. If your game is crashing, try to duplicate the crash. If you can narrow the crash down to a certain cause, you're much better off with getting a Solution to your Problem, because if you can reliably reproduce the issue and tell us HOW you reproduce it, we're much more likely to be able to see the Problem ourselves.
    Also bear in mind your Problem may just be a fluke. Maybe the stars aligned just wrong. Maybe it just ain't your lucky day. A good rule of thumb is three times - if the Problem appears three times, it isn't "just a fluke".
    Research the issue.
    Before you present your Problem, do a bit of research. Give the manual or readme of whatever's having issues a read - the manual/readme is certainly there for a reason. They may not have a troubleshooting section, but the Problem could be a simple issue with installation, especially if the Problem cropped up right after you installed a mod or reconfigured one.
    If nothing turns up in the manual, it's time to move onto the web. Search the forums for your issue, and look through the results. If you have an error code, search it. There's also a simple method that I use when searching that I refer to as "object-deviation" - as in, "object that's the issue, and deviation from how it normally works". (Side note: This is also a very good way to write your thread's title, as stated in the document linked above.)
    Good example: "GTA5 white police lights".
    If the Problem is an issue with a plugin, it's a good idea to look through your log files - sometimes, the error will be right there in plain sight, especially if it's a configuration issue.
    Note that verbosity isn't necessarily a good thing - a lot of forums will search EVERY word in the search bar, without omitting words like "the" or "are". If it's an issue with a mod, be sure to look through the file comments as well; someone may have had your Problem already and it may be solved already for you.
    If you get nothing on the forums, move on to Google, in quite the same fashion that you searched the forums.
    Sleep on it.
    No, I'm serious. Step away from the Problem for the day/night, regardless of how much you want it fixed here and now. Give it until tomorrow, after you wake up and have a level head, and are all refreshed. It's no use trying to diagnose your Problem while tired; you could easily miss important clues.
    When you post:
    Post in the correct forum. You'd be surprised at how many get moved or locked because they're in the wrong forum.
    Use a descriptive title.
    Some people will read every thread in the support fora, and there's nothing wrong with that. However, most people won't open a thread in a support forum unless the title catches their eye. Most people that look through the support fora will skim the thread titles. Using a descriptive title ensures that your Problem will be seen by someone before they even open the thread. As above, a good convention to use is "object-deviation" - "object of the issue-deviation from normalcy".
    VERY BAD: "GTA doesn't work" - Saying something "doesn't work" is the absolute kiss of death and will very likely cause the thread to be ignored. Saying it "doesn't work" is like a used-car salesman saying a car has wheels - it tells us nothing we don't already know, for if it did work as intended you wouldn't be asking for support. "GTA doesn't work" is not a question, and we're not interested in playing Twenty Questions to pry your actual Problem out of you.
    BAD: "GTA crashes" - It's the bare minimum you can get away with, but you can be more descriptive than that.
    GOOD: "GTA crashes when I drive near the prison" - You have a pretty decent, descriptive title here, saying exactly what's going on - GTA is crashing when you drive near the prison. It doesn't leave what the Problem is for guessing - it's all right there.
    Don't butcher the English language.
    No matter how much of an emergency getting your Problem fixed may seem, THERE IS NO NEED TO USE ALL-CAPITALS IN YOUR TEXT; MOST PEOPLE READ THIS AS SHOUTING. LIKE YOU PROBABLY JUST DID. The only notable exception to not using all-caps is to emphasize A SPECIFIC POINT, in moderation. (writing in all-lowercase is more tolerable, but on some typefaces is very hard to read.) Don't abbreviate unnecessarily, typng n smsspk lik this 2 sv k/s makes u look lik a semi-lit boob.
    If you write like you're a semi-literate boob, you're less likely to receive a Solution and more likely to be a zero-reply thread.
    Describe your problem and your troubleshooting steps.
    At the head of the post, you should re-describe the Problem in further detail and explain what you've tried. If there were any effects on the Problem at all - positive or negative, especially negative - list the effects as well. In doing so, less time is wasted on what you've already done and more can be spent on that which you haven't done.
    Attach relevant logs and configs. If it's an issue with a plugin or an ASI mod, attaching the logs could pin down your Problem to an issue. If it's a configuration issue, attaching your config file could help us point out where you went wrong.
    Leave questions open-ended.
    If you have a question about something, leave it open-ended. Yes-or-no questions get yes-or-no answers; leaving a question open-ended allows room for us to suggest a better way to do whatever it is you're trying to do.
    BAD: "How do I get a RGB car paint colour through a trainer?"
    GOOD: "I'm looking to get an RGB car paint colour from in the game. I'm trying to do it with a trainer but I don't see a way to do it - any suggestions?"
    Note how the way the second example is worded subtly encourages you to suggest something better-suited to the task than the trainer.
    Describe the Symptoms, not wild guesses.
    It's not useful to tell us your wild guesses as to what you think might be happening sans context - if your diagnostic theories were correct, you wouldn't have a Problem to post in the first place. Write down what your Problem's symptoms are and let us see what we can do. That's not to say educated guesses aren't alright - in fact, they're more than OK if you can tell us how you came to that conclusion; but if you can't give us a logical, rational explanation on how you came up with your guess, you're better off not posting it.
    Keep public support requests to public channels.
    Problem solving should be public - if someone else comes upon your Problem later, they can look at your thread and see any Solutions that you may be given. There may be reasons for taking something to PM, but unless you're specifically asked to, you should leave it public - taking it to private channels without permission is generally seen as rude.
    Now that you've posted:
    Keep looking for possible Solutions.
    If you find a Solution to your Problem before someone else does, edit your post and tack on the solution, and make the title clear that it's solved. If you say "nevermind, got it" you look like a dick for not posting what you did to fix it, to any future Solution-seeker that may happen to stumble across your thread.

    (Above image copyright 2011 Randall Munroe. Link to source)
    Don't mistake bluntness for rudeness.
    A lot of communications for a lot of people revolve around tact and courtesy - not here. As you can tell by the way this is written, people here to help you solve problems are very seldom here to make you feel warm and fuzzy in doing so. We're not here to offend you, we're just cutting through the unnecessary fluff.
    If you feel someone's being rude, keep cool. If they really are being rude, someone will call them out on it. If they don't and you lose your temper, it's quite possible that whoever you just lost it on was behaving within the community's norms. Most flames are best left to burn themselves out - after, of course, you've checked that they're really flames, and not hidden Solutions to your Problem.
    Don't immediately demand clarification for Solutions you don't understand.
    Yes, you read that right. If you don't understand, you should use the tools you used to try to find your Solution before you posted it (Google, forum search, manuals, logs, etc.) to try to understand the Solution you've been given. If you're still stumped, THEN ask for clarification.
    BAD: "What do you mean 'set SECL to DROT'?"
    GOOD: "I read the manual, but I didn't see anything about DROT under 'SECL'. I did find DROT under 'PRML', and 'ROTA' under 'SECL', though; is it one of these or am I missing something?"
    Don't bump your thread.
    No matter how long it's been, have a bit of patience: no response isn't the same as being ignored, though it may be difficult to tell the difference. Bumping your thread may be seen as a sign of impatience to those that may be trying to help. Also, bear in mind the size of the Earth - even if it's high noon where you live, someone with a potential Solution may be fast asleep at 2 in the morning where they live.
    In Conclusion
    A lot of our ability to give Solutions depends on your ability to provide information. Threads with a lot of useful information are easier to provide Solutions for, whereas Problems with absolutely no information listed are nigh impossible without us having to force the information out of you. By using the above guide, you greatly increase the odds of getting a useful Solution to your Problem, and you may even learn a thing or two in the process.
  2. Like
    EvilJackCarver got a reaction from Giordano in LSPDFR 0.4 - Announcement + First Preview   
    When it's ready, as previously stated at least thrice in this thread.
  3. Like
  4. Like
    EvilJackCarver reacted to Jules Winnfield in Petition to Take-Two Interactive & Rockstar Games RE: OpenIV closing   
    Petitions do nothing. You aren't going to win over a multi-million dollar company.
     
    What you people need to be petitioning is having the retards over at OpenIV stop forcing users to uninstall their software. This alone is a violation of the user's rights. There is no reason to force a user to uninstall your software because some lawyer at T2I said they don't like custom modifications.
     
    That being said, I sure am glad I got out of this shit before this went down.
     
  5. Like
    EvilJackCarver got a reaction from Prophet in Setup Wars! Show us your spot!   
    Hell, why not.
    Fair warning, my desk is a mess.
     
  6. Like
    EvilJackCarver got a reaction from Original Light in [GUIDE] Getting useful Solutions to your Problems   
    Notes for modstaff in spoiler.
    Preface
    This text was adapted from a document by Eric S. Raymond, titled How to Ask Questions the Smart Way. The full document is available here - the authors of this document are in no way affiliated with G17 Media nor myself, and aren't there to answer your questions about how to get whatever it is you're trying to get working, working.
    Introduction
    If you're reading this, hi there. I suck at smalltalk and making things sound nice, so I'll open with this: In the world of diagnostics, there are a few right ways to get Solutions... and many, many wrong ways. This post is here to hopefully help nudge you toward the right ways, so that you can get the Solutions you want easier.
    Of course, getting a good Solution isn't just on the people helping you solve your Problems - and you're naïve if you think that. A lot of the work needed to solve a Problem falls on you. A vast majority of the time, whether the issue gets solved depends not on the Problem itself, rather what the end user did to troubleshoot and what information they posted in their support threads.
    Depending on how you present your issue and what it may or may not contain, your Problem's thread may get zero replies, or a hundred; it may be solved in an hour, a week, or it may remain an unsolved mystery. This post is here to reduce the odds of that last bit.
    Still with me? Let's begin.
    Before you post:
    Reproduce the issue.
    Try to reproduce the Problem. If your game is crashing, try to duplicate the crash. If you can narrow the crash down to a certain cause, you're much better off with getting a Solution to your Problem, because if you can reliably reproduce the issue and tell us HOW you reproduce it, we're much more likely to be able to see the Problem ourselves.
    Also bear in mind your Problem may just be a fluke. Maybe the stars aligned just wrong. Maybe it just ain't your lucky day. A good rule of thumb is three times - if the Problem appears three times, it isn't "just a fluke".
    Research the issue.
    Before you present your Problem, do a bit of research. Give the manual or readme of whatever's having issues a read - the manual/readme is certainly there for a reason. They may not have a troubleshooting section, but the Problem could be a simple issue with installation, especially if the Problem cropped up right after you installed a mod or reconfigured one.
    If nothing turns up in the manual, it's time to move onto the web. Search the forums for your issue, and look through the results. If you have an error code, search it. There's also a simple method that I use when searching that I refer to as "object-deviation" - as in, "object that's the issue, and deviation from how it normally works". (Side note: This is also a very good way to write your thread's title, as stated in the document linked above.)
    Good example: "GTA5 white police lights".
    If the Problem is an issue with a plugin, it's a good idea to look through your log files - sometimes, the error will be right there in plain sight, especially if it's a configuration issue.
    Note that verbosity isn't necessarily a good thing - a lot of forums will search EVERY word in the search bar, without omitting words like "the" or "are". If it's an issue with a mod, be sure to look through the file comments as well; someone may have had your Problem already and it may be solved already for you.
    If you get nothing on the forums, move on to Google, in quite the same fashion that you searched the forums.
    Sleep on it.
    No, I'm serious. Step away from the Problem for the day/night, regardless of how much you want it fixed here and now. Give it until tomorrow, after you wake up and have a level head, and are all refreshed. It's no use trying to diagnose your Problem while tired; you could easily miss important clues.
    When you post:
    Post in the correct forum. You'd be surprised at how many get moved or locked because they're in the wrong forum.
    Use a descriptive title.
    Some people will read every thread in the support fora, and there's nothing wrong with that. However, most people won't open a thread in a support forum unless the title catches their eye. Most people that look through the support fora will skim the thread titles. Using a descriptive title ensures that your Problem will be seen by someone before they even open the thread. As above, a good convention to use is "object-deviation" - "object of the issue-deviation from normalcy".
    VERY BAD: "GTA doesn't work" - Saying something "doesn't work" is the absolute kiss of death and will very likely cause the thread to be ignored. Saying it "doesn't work" is like a used-car salesman saying a car has wheels - it tells us nothing we don't already know, for if it did work as intended you wouldn't be asking for support. "GTA doesn't work" is not a question, and we're not interested in playing Twenty Questions to pry your actual Problem out of you.
    BAD: "GTA crashes" - It's the bare minimum you can get away with, but you can be more descriptive than that.
    GOOD: "GTA crashes when I drive near the prison" - You have a pretty decent, descriptive title here, saying exactly what's going on - GTA is crashing when you drive near the prison. It doesn't leave what the Problem is for guessing - it's all right there.
    Don't butcher the English language.
    No matter how much of an emergency getting your Problem fixed may seem, THERE IS NO NEED TO USE ALL-CAPITALS IN YOUR TEXT; MOST PEOPLE READ THIS AS SHOUTING. LIKE YOU PROBABLY JUST DID. The only notable exception to not using all-caps is to emphasize A SPECIFIC POINT, in moderation. (writing in all-lowercase is more tolerable, but on some typefaces is very hard to read.) Don't abbreviate unnecessarily, typng n smsspk lik this 2 sv k/s makes u look lik a semi-lit boob.
    If you write like you're a semi-literate boob, you're less likely to receive a Solution and more likely to be a zero-reply thread.
    Describe your problem and your troubleshooting steps.
    At the head of the post, you should re-describe the Problem in further detail and explain what you've tried. If there were any effects on the Problem at all - positive or negative, especially negative - list the effects as well. In doing so, less time is wasted on what you've already done and more can be spent on that which you haven't done.
    Attach relevant logs and configs. If it's an issue with a plugin or an ASI mod, attaching the logs could pin down your Problem to an issue. If it's a configuration issue, attaching your config file could help us point out where you went wrong.
    Leave questions open-ended.
    If you have a question about something, leave it open-ended. Yes-or-no questions get yes-or-no answers; leaving a question open-ended allows room for us to suggest a better way to do whatever it is you're trying to do.
    BAD: "How do I get a RGB car paint colour through a trainer?"
    GOOD: "I'm looking to get an RGB car paint colour from in the game. I'm trying to do it with a trainer but I don't see a way to do it - any suggestions?"
    Note how the way the second example is worded subtly encourages you to suggest something better-suited to the task than the trainer.
    Describe the Symptoms, not wild guesses.
    It's not useful to tell us your wild guesses as to what you think might be happening sans context - if your diagnostic theories were correct, you wouldn't have a Problem to post in the first place. Write down what your Problem's symptoms are and let us see what we can do. That's not to say educated guesses aren't alright - in fact, they're more than OK if you can tell us how you came to that conclusion; but if you can't give us a logical, rational explanation on how you came up with your guess, you're better off not posting it.
    Keep public support requests to public channels.
    Problem solving should be public - if someone else comes upon your Problem later, they can look at your thread and see any Solutions that you may be given. There may be reasons for taking something to PM, but unless you're specifically asked to, you should leave it public - taking it to private channels without permission is generally seen as rude.
    Now that you've posted:
    Keep looking for possible Solutions.
    If you find a Solution to your Problem before someone else does, edit your post and tack on the solution, and make the title clear that it's solved. If you say "nevermind, got it" you look like a dick for not posting what you did to fix it, to any future Solution-seeker that may happen to stumble across your thread.

    (Above image copyright 2011 Randall Munroe. Link to source)
    Don't mistake bluntness for rudeness.
    A lot of communications for a lot of people revolve around tact and courtesy - not here. As you can tell by the way this is written, people here to help you solve problems are very seldom here to make you feel warm and fuzzy in doing so. We're not here to offend you, we're just cutting through the unnecessary fluff.
    If you feel someone's being rude, keep cool. If they really are being rude, someone will call them out on it. If they don't and you lose your temper, it's quite possible that whoever you just lost it on was behaving within the community's norms. Most flames are best left to burn themselves out - after, of course, you've checked that they're really flames, and not hidden Solutions to your Problem.
    Don't immediately demand clarification for Solutions you don't understand.
    Yes, you read that right. If you don't understand, you should use the tools you used to try to find your Solution before you posted it (Google, forum search, manuals, logs, etc.) to try to understand the Solution you've been given. If you're still stumped, THEN ask for clarification.
    BAD: "What do you mean 'set SECL to DROT'?"
    GOOD: "I read the manual, but I didn't see anything about DROT under 'SECL'. I did find DROT under 'PRML', and 'ROTA' under 'SECL', though; is it one of these or am I missing something?"
    Don't bump your thread.
    No matter how long it's been, have a bit of patience: no response isn't the same as being ignored, though it may be difficult to tell the difference. Bumping your thread may be seen as a sign of impatience to those that may be trying to help. Also, bear in mind the size of the Earth - even if it's high noon where you live, someone with a potential Solution may be fast asleep at 2 in the morning where they live.
    In Conclusion
    A lot of our ability to give Solutions depends on your ability to provide information. Threads with a lot of useful information are easier to provide Solutions for, whereas Problems with absolutely no information listed are nigh impossible without us having to force the information out of you. By using the above guide, you greatly increase the odds of getting a useful Solution to your Problem, and you may even learn a thing or two in the process.
  7. Like
    EvilJackCarver got a reaction from LtFlash in Favorite Police Vehicle?   
    '92 Caprice.
     
  8. Like
    EvilJackCarver got a reaction from Fossy in Police sirens don't have any reflections, blur.   
    Up your shaders, see if that works.
     
    Note: On downloaded cars that don't use siren coronas, there won't be any environmental reflections or vanilla=style "flashing". An easy way to tell if your car uses coronas or not would be to flip the car with the lightbar on and look under it - if there are lights under your undercarriage, the car doesn't use coronas. A lot of modders put their coronas well down there so they can have all-blue, yellow, or other light colours in the lightbar without reflections being off.
  9. Like
    EvilJackCarver got a reaction from Original Light in Horrible Framerate when on-duty   
    It's most likely Rockstar's countermeasures against modding.
     
     
  10. Like
    EvilJackCarver got a reaction from Original Light in [GUIDE] Getting useful Solutions to your Problems   
    Notes for modstaff in spoiler.
    Preface
    This text was adapted from a document by Eric S. Raymond, titled How to Ask Questions the Smart Way. The full document is available here - the authors of this document are in no way affiliated with G17 Media nor myself, and aren't there to answer your questions about how to get whatever it is you're trying to get working, working.
    Introduction
    If you're reading this, hi there. I suck at smalltalk and making things sound nice, so I'll open with this: In the world of diagnostics, there are a few right ways to get Solutions... and many, many wrong ways. This post is here to hopefully help nudge you toward the right ways, so that you can get the Solutions you want easier.
    Of course, getting a good Solution isn't just on the people helping you solve your Problems - and you're naïve if you think that. A lot of the work needed to solve a Problem falls on you. A vast majority of the time, whether the issue gets solved depends not on the Problem itself, rather what the end user did to troubleshoot and what information they posted in their support threads.
    Depending on how you present your issue and what it may or may not contain, your Problem's thread may get zero replies, or a hundred; it may be solved in an hour, a week, or it may remain an unsolved mystery. This post is here to reduce the odds of that last bit.
    Still with me? Let's begin.
    Before you post:
    Reproduce the issue.
    Try to reproduce the Problem. If your game is crashing, try to duplicate the crash. If you can narrow the crash down to a certain cause, you're much better off with getting a Solution to your Problem, because if you can reliably reproduce the issue and tell us HOW you reproduce it, we're much more likely to be able to see the Problem ourselves.
    Also bear in mind your Problem may just be a fluke. Maybe the stars aligned just wrong. Maybe it just ain't your lucky day. A good rule of thumb is three times - if the Problem appears three times, it isn't "just a fluke".
    Research the issue.
    Before you present your Problem, do a bit of research. Give the manual or readme of whatever's having issues a read - the manual/readme is certainly there for a reason. They may not have a troubleshooting section, but the Problem could be a simple issue with installation, especially if the Problem cropped up right after you installed a mod or reconfigured one.
    If nothing turns up in the manual, it's time to move onto the web. Search the forums for your issue, and look through the results. If you have an error code, search it. There's also a simple method that I use when searching that I refer to as "object-deviation" - as in, "object that's the issue, and deviation from how it normally works". (Side note: This is also a very good way to write your thread's title, as stated in the document linked above.)
    Good example: "GTA5 white police lights".
    If the Problem is an issue with a plugin, it's a good idea to look through your log files - sometimes, the error will be right there in plain sight, especially if it's a configuration issue.
    Note that verbosity isn't necessarily a good thing - a lot of forums will search EVERY word in the search bar, without omitting words like "the" or "are". If it's an issue with a mod, be sure to look through the file comments as well; someone may have had your Problem already and it may be solved already for you.
    If you get nothing on the forums, move on to Google, in quite the same fashion that you searched the forums.
    Sleep on it.
    No, I'm serious. Step away from the Problem for the day/night, regardless of how much you want it fixed here and now. Give it until tomorrow, after you wake up and have a level head, and are all refreshed. It's no use trying to diagnose your Problem while tired; you could easily miss important clues.
    When you post:
    Post in the correct forum. You'd be surprised at how many get moved or locked because they're in the wrong forum.
    Use a descriptive title.
    Some people will read every thread in the support fora, and there's nothing wrong with that. However, most people won't open a thread in a support forum unless the title catches their eye. Most people that look through the support fora will skim the thread titles. Using a descriptive title ensures that your Problem will be seen by someone before they even open the thread. As above, a good convention to use is "object-deviation" - "object of the issue-deviation from normalcy".
    VERY BAD: "GTA doesn't work" - Saying something "doesn't work" is the absolute kiss of death and will very likely cause the thread to be ignored. Saying it "doesn't work" is like a used-car salesman saying a car has wheels - it tells us nothing we don't already know, for if it did work as intended you wouldn't be asking for support. "GTA doesn't work" is not a question, and we're not interested in playing Twenty Questions to pry your actual Problem out of you.
    BAD: "GTA crashes" - It's the bare minimum you can get away with, but you can be more descriptive than that.
    GOOD: "GTA crashes when I drive near the prison" - You have a pretty decent, descriptive title here, saying exactly what's going on - GTA is crashing when you drive near the prison. It doesn't leave what the Problem is for guessing - it's all right there.
    Don't butcher the English language.
    No matter how much of an emergency getting your Problem fixed may seem, THERE IS NO NEED TO USE ALL-CAPITALS IN YOUR TEXT; MOST PEOPLE READ THIS AS SHOUTING. LIKE YOU PROBABLY JUST DID. The only notable exception to not using all-caps is to emphasize A SPECIFIC POINT, in moderation. (writing in all-lowercase is more tolerable, but on some typefaces is very hard to read.) Don't abbreviate unnecessarily, typng n smsspk lik this 2 sv k/s makes u look lik a semi-lit boob.
    If you write like you're a semi-literate boob, you're less likely to receive a Solution and more likely to be a zero-reply thread.
    Describe your problem and your troubleshooting steps.
    At the head of the post, you should re-describe the Problem in further detail and explain what you've tried. If there were any effects on the Problem at all - positive or negative, especially negative - list the effects as well. In doing so, less time is wasted on what you've already done and more can be spent on that which you haven't done.
    Attach relevant logs and configs. If it's an issue with a plugin or an ASI mod, attaching the logs could pin down your Problem to an issue. If it's a configuration issue, attaching your config file could help us point out where you went wrong.
    Leave questions open-ended.
    If you have a question about something, leave it open-ended. Yes-or-no questions get yes-or-no answers; leaving a question open-ended allows room for us to suggest a better way to do whatever it is you're trying to do.
    BAD: "How do I get a RGB car paint colour through a trainer?"
    GOOD: "I'm looking to get an RGB car paint colour from in the game. I'm trying to do it with a trainer but I don't see a way to do it - any suggestions?"
    Note how the way the second example is worded subtly encourages you to suggest something better-suited to the task than the trainer.
    Describe the Symptoms, not wild guesses.
    It's not useful to tell us your wild guesses as to what you think might be happening sans context - if your diagnostic theories were correct, you wouldn't have a Problem to post in the first place. Write down what your Problem's symptoms are and let us see what we can do. That's not to say educated guesses aren't alright - in fact, they're more than OK if you can tell us how you came to that conclusion; but if you can't give us a logical, rational explanation on how you came up with your guess, you're better off not posting it.
    Keep public support requests to public channels.
    Problem solving should be public - if someone else comes upon your Problem later, they can look at your thread and see any Solutions that you may be given. There may be reasons for taking something to PM, but unless you're specifically asked to, you should leave it public - taking it to private channels without permission is generally seen as rude.
    Now that you've posted:
    Keep looking for possible Solutions.
    If you find a Solution to your Problem before someone else does, edit your post and tack on the solution, and make the title clear that it's solved. If you say "nevermind, got it" you look like a dick for not posting what you did to fix it, to any future Solution-seeker that may happen to stumble across your thread.

    (Above image copyright 2011 Randall Munroe. Link to source)
    Don't mistake bluntness for rudeness.
    A lot of communications for a lot of people revolve around tact and courtesy - not here. As you can tell by the way this is written, people here to help you solve problems are very seldom here to make you feel warm and fuzzy in doing so. We're not here to offend you, we're just cutting through the unnecessary fluff.
    If you feel someone's being rude, keep cool. If they really are being rude, someone will call them out on it. If they don't and you lose your temper, it's quite possible that whoever you just lost it on was behaving within the community's norms. Most flames are best left to burn themselves out - after, of course, you've checked that they're really flames, and not hidden Solutions to your Problem.
    Don't immediately demand clarification for Solutions you don't understand.
    Yes, you read that right. If you don't understand, you should use the tools you used to try to find your Solution before you posted it (Google, forum search, manuals, logs, etc.) to try to understand the Solution you've been given. If you're still stumped, THEN ask for clarification.
    BAD: "What do you mean 'set SECL to DROT'?"
    GOOD: "I read the manual, but I didn't see anything about DROT under 'SECL'. I did find DROT under 'PRML', and 'ROTA' under 'SECL', though; is it one of these or am I missing something?"
    Don't bump your thread.
    No matter how long it's been, have a bit of patience: no response isn't the same as being ignored, though it may be difficult to tell the difference. Bumping your thread may be seen as a sign of impatience to those that may be trying to help. Also, bear in mind the size of the Earth - even if it's high noon where you live, someone with a potential Solution may be fast asleep at 2 in the morning where they live.
    In Conclusion
    A lot of our ability to give Solutions depends on your ability to provide information. Threads with a lot of useful information are easier to provide Solutions for, whereas Problems with absolutely no information listed are nigh impossible without us having to force the information out of you. By using the above guide, you greatly increase the odds of getting a useful Solution to your Problem, and you may even learn a thing or two in the process.
  11. Like
    EvilJackCarver reacted to SuperStumpje in Easy anyone should know but i dont..   
    If you're talking about the information display, I know for a fact that's described in the documentation that comes with ELS. You could of course also just check the config file for keybinds you don't know and try them ingame.
  12. Like
    EvilJackCarver got a reaction from Original Light in Horrible Framerate when on-duty   
    It's most likely Rockstar's countermeasures against modding.
     
     
  13. Like
    EvilJackCarver reacted to Fiskey111 in [ Request for LSPDFR 0.4 ]   
    No, I am not a developer of LSPDFR.  I'm sure it will be out sometime though!
  14. Like
    EvilJackCarver got a reaction from tragicEM in WISH LIST/   
    TYPING IN ALL CAPS IS SHOUTING. SHOUTING IS RUDE. Caps in moderation, such as to EMPHASIZE A PHRASE is alright - don't get me wrong - but you cann't get away with shouting at someone on the street six inches away from their face, and then call them rude when they point out you're shouting; you're likely to get backhanded around here if you do. In addition, you're not helping your case any by pointing out that my reply was directed at you and not the topic.  
    Modelling, especially from scratch, takes time and effort. I've not seen a single Durango, Caliber Magnum or Caravan model ported to GTA5 yet, and porting also takes time and effort. If you want it, you can either do it yourself, or find someone and ask them if they're taking requests. If they say no, don't go further with them. Either way, you should probably be prepared to pay - you can buy an prefab model and commission a GTA5-ready model, buy a prefab and convert it yourself...

    In other words: Fast, good, cheap. Pick two. I've nothing more to say on this thread, good day.
  15. Like
    EvilJackCarver got a reaction from Albo1125 in Mod to spawn things in   
    You could use RPH's "spawn" command, or a trainer.
  16. Like
    EvilJackCarver got a reaction from Original Light in [GUIDE] Getting useful Solutions to your Problems   
    Notes for modstaff in spoiler.
    Preface
    This text was adapted from a document by Eric S. Raymond, titled How to Ask Questions the Smart Way. The full document is available here - the authors of this document are in no way affiliated with G17 Media nor myself, and aren't there to answer your questions about how to get whatever it is you're trying to get working, working.
    Introduction
    If you're reading this, hi there. I suck at smalltalk and making things sound nice, so I'll open with this: In the world of diagnostics, there are a few right ways to get Solutions... and many, many wrong ways. This post is here to hopefully help nudge you toward the right ways, so that you can get the Solutions you want easier.
    Of course, getting a good Solution isn't just on the people helping you solve your Problems - and you're naïve if you think that. A lot of the work needed to solve a Problem falls on you. A vast majority of the time, whether the issue gets solved depends not on the Problem itself, rather what the end user did to troubleshoot and what information they posted in their support threads.
    Depending on how you present your issue and what it may or may not contain, your Problem's thread may get zero replies, or a hundred; it may be solved in an hour, a week, or it may remain an unsolved mystery. This post is here to reduce the odds of that last bit.
    Still with me? Let's begin.
    Before you post:
    Reproduce the issue.
    Try to reproduce the Problem. If your game is crashing, try to duplicate the crash. If you can narrow the crash down to a certain cause, you're much better off with getting a Solution to your Problem, because if you can reliably reproduce the issue and tell us HOW you reproduce it, we're much more likely to be able to see the Problem ourselves.
    Also bear in mind your Problem may just be a fluke. Maybe the stars aligned just wrong. Maybe it just ain't your lucky day. A good rule of thumb is three times - if the Problem appears three times, it isn't "just a fluke".
    Research the issue.
    Before you present your Problem, do a bit of research. Give the manual or readme of whatever's having issues a read - the manual/readme is certainly there for a reason. They may not have a troubleshooting section, but the Problem could be a simple issue with installation, especially if the Problem cropped up right after you installed a mod or reconfigured one.
    If nothing turns up in the manual, it's time to move onto the web. Search the forums for your issue, and look through the results. If you have an error code, search it. There's also a simple method that I use when searching that I refer to as "object-deviation" - as in, "object that's the issue, and deviation from how it normally works". (Side note: This is also a very good way to write your thread's title, as stated in the document linked above.)
    Good example: "GTA5 white police lights".
    If the Problem is an issue with a plugin, it's a good idea to look through your log files - sometimes, the error will be right there in plain sight, especially if it's a configuration issue.
    Note that verbosity isn't necessarily a good thing - a lot of forums will search EVERY word in the search bar, without omitting words like "the" or "are". If it's an issue with a mod, be sure to look through the file comments as well; someone may have had your Problem already and it may be solved already for you.
    If you get nothing on the forums, move on to Google, in quite the same fashion that you searched the forums.
    Sleep on it.
    No, I'm serious. Step away from the Problem for the day/night, regardless of how much you want it fixed here and now. Give it until tomorrow, after you wake up and have a level head, and are all refreshed. It's no use trying to diagnose your Problem while tired; you could easily miss important clues.
    When you post:
    Post in the correct forum. You'd be surprised at how many get moved or locked because they're in the wrong forum.
    Use a descriptive title.
    Some people will read every thread in the support fora, and there's nothing wrong with that. However, most people won't open a thread in a support forum unless the title catches their eye. Most people that look through the support fora will skim the thread titles. Using a descriptive title ensures that your Problem will be seen by someone before they even open the thread. As above, a good convention to use is "object-deviation" - "object of the issue-deviation from normalcy".
    VERY BAD: "GTA doesn't work" - Saying something "doesn't work" is the absolute kiss of death and will very likely cause the thread to be ignored. Saying it "doesn't work" is like a used-car salesman saying a car has wheels - it tells us nothing we don't already know, for if it did work as intended you wouldn't be asking for support. "GTA doesn't work" is not a question, and we're not interested in playing Twenty Questions to pry your actual Problem out of you.
    BAD: "GTA crashes" - It's the bare minimum you can get away with, but you can be more descriptive than that.
    GOOD: "GTA crashes when I drive near the prison" - You have a pretty decent, descriptive title here, saying exactly what's going on - GTA is crashing when you drive near the prison. It doesn't leave what the Problem is for guessing - it's all right there.
    Don't butcher the English language.
    No matter how much of an emergency getting your Problem fixed may seem, THERE IS NO NEED TO USE ALL-CAPITALS IN YOUR TEXT; MOST PEOPLE READ THIS AS SHOUTING. LIKE YOU PROBABLY JUST DID. The only notable exception to not using all-caps is to emphasize A SPECIFIC POINT, in moderation. (writing in all-lowercase is more tolerable, but on some typefaces is very hard to read.) Don't abbreviate unnecessarily, typng n smsspk lik this 2 sv k/s makes u look lik a semi-lit boob.
    If you write like you're a semi-literate boob, you're less likely to receive a Solution and more likely to be a zero-reply thread.
    Describe your problem and your troubleshooting steps.
    At the head of the post, you should re-describe the Problem in further detail and explain what you've tried. If there were any effects on the Problem at all - positive or negative, especially negative - list the effects as well. In doing so, less time is wasted on what you've already done and more can be spent on that which you haven't done.
    Attach relevant logs and configs. If it's an issue with a plugin or an ASI mod, attaching the logs could pin down your Problem to an issue. If it's a configuration issue, attaching your config file could help us point out where you went wrong.
    Leave questions open-ended.
    If you have a question about something, leave it open-ended. Yes-or-no questions get yes-or-no answers; leaving a question open-ended allows room for us to suggest a better way to do whatever it is you're trying to do.
    BAD: "How do I get a RGB car paint colour through a trainer?"
    GOOD: "I'm looking to get an RGB car paint colour from in the game. I'm trying to do it with a trainer but I don't see a way to do it - any suggestions?"
    Note how the way the second example is worded subtly encourages you to suggest something better-suited to the task than the trainer.
    Describe the Symptoms, not wild guesses.
    It's not useful to tell us your wild guesses as to what you think might be happening sans context - if your diagnostic theories were correct, you wouldn't have a Problem to post in the first place. Write down what your Problem's symptoms are and let us see what we can do. That's not to say educated guesses aren't alright - in fact, they're more than OK if you can tell us how you came to that conclusion; but if you can't give us a logical, rational explanation on how you came up with your guess, you're better off not posting it.
    Keep public support requests to public channels.
    Problem solving should be public - if someone else comes upon your Problem later, they can look at your thread and see any Solutions that you may be given. There may be reasons for taking something to PM, but unless you're specifically asked to, you should leave it public - taking it to private channels without permission is generally seen as rude.
    Now that you've posted:
    Keep looking for possible Solutions.
    If you find a Solution to your Problem before someone else does, edit your post and tack on the solution, and make the title clear that it's solved. If you say "nevermind, got it" you look like a dick for not posting what you did to fix it, to any future Solution-seeker that may happen to stumble across your thread.

    (Above image copyright 2011 Randall Munroe. Link to source)
    Don't mistake bluntness for rudeness.
    A lot of communications for a lot of people revolve around tact and courtesy - not here. As you can tell by the way this is written, people here to help you solve problems are very seldom here to make you feel warm and fuzzy in doing so. We're not here to offend you, we're just cutting through the unnecessary fluff.
    If you feel someone's being rude, keep cool. If they really are being rude, someone will call them out on it. If they don't and you lose your temper, it's quite possible that whoever you just lost it on was behaving within the community's norms. Most flames are best left to burn themselves out - after, of course, you've checked that they're really flames, and not hidden Solutions to your Problem.
    Don't immediately demand clarification for Solutions you don't understand.
    Yes, you read that right. If you don't understand, you should use the tools you used to try to find your Solution before you posted it (Google, forum search, manuals, logs, etc.) to try to understand the Solution you've been given. If you're still stumped, THEN ask for clarification.
    BAD: "What do you mean 'set SECL to DROT'?"
    GOOD: "I read the manual, but I didn't see anything about DROT under 'SECL'. I did find DROT under 'PRML', and 'ROTA' under 'SECL', though; is it one of these or am I missing something?"
    Don't bump your thread.
    No matter how long it's been, have a bit of patience: no response isn't the same as being ignored, though it may be difficult to tell the difference. Bumping your thread may be seen as a sign of impatience to those that may be trying to help. Also, bear in mind the size of the Earth - even if it's high noon where you live, someone with a potential Solution may be fast asleep at 2 in the morning where they live.
    In Conclusion
    A lot of our ability to give Solutions depends on your ability to provide information. Threads with a lot of useful information are easier to provide Solutions for, whereas Problems with absolutely no information listed are nigh impossible without us having to force the information out of you. By using the above guide, you greatly increase the odds of getting a useful Solution to your Problem, and you may even learn a thing or two in the process.
  17. Like
    EvilJackCarver got a reaction from Original Light in [GUIDE] Getting useful Solutions to your Problems   
    Notes for modstaff in spoiler.
    Preface
    This text was adapted from a document by Eric S. Raymond, titled How to Ask Questions the Smart Way. The full document is available here - the authors of this document are in no way affiliated with G17 Media nor myself, and aren't there to answer your questions about how to get whatever it is you're trying to get working, working.
    Introduction
    If you're reading this, hi there. I suck at smalltalk and making things sound nice, so I'll open with this: In the world of diagnostics, there are a few right ways to get Solutions... and many, many wrong ways. This post is here to hopefully help nudge you toward the right ways, so that you can get the Solutions you want easier.
    Of course, getting a good Solution isn't just on the people helping you solve your Problems - and you're naïve if you think that. A lot of the work needed to solve a Problem falls on you. A vast majority of the time, whether the issue gets solved depends not on the Problem itself, rather what the end user did to troubleshoot and what information they posted in their support threads.
    Depending on how you present your issue and what it may or may not contain, your Problem's thread may get zero replies, or a hundred; it may be solved in an hour, a week, or it may remain an unsolved mystery. This post is here to reduce the odds of that last bit.
    Still with me? Let's begin.
    Before you post:
    Reproduce the issue.
    Try to reproduce the Problem. If your game is crashing, try to duplicate the crash. If you can narrow the crash down to a certain cause, you're much better off with getting a Solution to your Problem, because if you can reliably reproduce the issue and tell us HOW you reproduce it, we're much more likely to be able to see the Problem ourselves.
    Also bear in mind your Problem may just be a fluke. Maybe the stars aligned just wrong. Maybe it just ain't your lucky day. A good rule of thumb is three times - if the Problem appears three times, it isn't "just a fluke".
    Research the issue.
    Before you present your Problem, do a bit of research. Give the manual or readme of whatever's having issues a read - the manual/readme is certainly there for a reason. They may not have a troubleshooting section, but the Problem could be a simple issue with installation, especially if the Problem cropped up right after you installed a mod or reconfigured one.
    If nothing turns up in the manual, it's time to move onto the web. Search the forums for your issue, and look through the results. If you have an error code, search it. There's also a simple method that I use when searching that I refer to as "object-deviation" - as in, "object that's the issue, and deviation from how it normally works". (Side note: This is also a very good way to write your thread's title, as stated in the document linked above.)
    Good example: "GTA5 white police lights".
    If the Problem is an issue with a plugin, it's a good idea to look through your log files - sometimes, the error will be right there in plain sight, especially if it's a configuration issue.
    Note that verbosity isn't necessarily a good thing - a lot of forums will search EVERY word in the search bar, without omitting words like "the" or "are". If it's an issue with a mod, be sure to look through the file comments as well; someone may have had your Problem already and it may be solved already for you.
    If you get nothing on the forums, move on to Google, in quite the same fashion that you searched the forums.
    Sleep on it.
    No, I'm serious. Step away from the Problem for the day/night, regardless of how much you want it fixed here and now. Give it until tomorrow, after you wake up and have a level head, and are all refreshed. It's no use trying to diagnose your Problem while tired; you could easily miss important clues.
    When you post:
    Post in the correct forum. You'd be surprised at how many get moved or locked because they're in the wrong forum.
    Use a descriptive title.
    Some people will read every thread in the support fora, and there's nothing wrong with that. However, most people won't open a thread in a support forum unless the title catches their eye. Most people that look through the support fora will skim the thread titles. Using a descriptive title ensures that your Problem will be seen by someone before they even open the thread. As above, a good convention to use is "object-deviation" - "object of the issue-deviation from normalcy".
    VERY BAD: "GTA doesn't work" - Saying something "doesn't work" is the absolute kiss of death and will very likely cause the thread to be ignored. Saying it "doesn't work" is like a used-car salesman saying a car has wheels - it tells us nothing we don't already know, for if it did work as intended you wouldn't be asking for support. "GTA doesn't work" is not a question, and we're not interested in playing Twenty Questions to pry your actual Problem out of you.
    BAD: "GTA crashes" - It's the bare minimum you can get away with, but you can be more descriptive than that.
    GOOD: "GTA crashes when I drive near the prison" - You have a pretty decent, descriptive title here, saying exactly what's going on - GTA is crashing when you drive near the prison. It doesn't leave what the Problem is for guessing - it's all right there.
    Don't butcher the English language.
    No matter how much of an emergency getting your Problem fixed may seem, THERE IS NO NEED TO USE ALL-CAPITALS IN YOUR TEXT; MOST PEOPLE READ THIS AS SHOUTING. LIKE YOU PROBABLY JUST DID. The only notable exception to not using all-caps is to emphasize A SPECIFIC POINT, in moderation. (writing in all-lowercase is more tolerable, but on some typefaces is very hard to read.) Don't abbreviate unnecessarily, typng n smsspk lik this 2 sv k/s makes u look lik a semi-lit boob.
    If you write like you're a semi-literate boob, you're less likely to receive a Solution and more likely to be a zero-reply thread.
    Describe your problem and your troubleshooting steps.
    At the head of the post, you should re-describe the Problem in further detail and explain what you've tried. If there were any effects on the Problem at all - positive or negative, especially negative - list the effects as well. In doing so, less time is wasted on what you've already done and more can be spent on that which you haven't done.
    Attach relevant logs and configs. If it's an issue with a plugin or an ASI mod, attaching the logs could pin down your Problem to an issue. If it's a configuration issue, attaching your config file could help us point out where you went wrong.
    Leave questions open-ended.
    If you have a question about something, leave it open-ended. Yes-or-no questions get yes-or-no answers; leaving a question open-ended allows room for us to suggest a better way to do whatever it is you're trying to do.
    BAD: "How do I get a RGB car paint colour through a trainer?"
    GOOD: "I'm looking to get an RGB car paint colour from in the game. I'm trying to do it with a trainer but I don't see a way to do it - any suggestions?"
    Note how the way the second example is worded subtly encourages you to suggest something better-suited to the task than the trainer.
    Describe the Symptoms, not wild guesses.
    It's not useful to tell us your wild guesses as to what you think might be happening sans context - if your diagnostic theories were correct, you wouldn't have a Problem to post in the first place. Write down what your Problem's symptoms are and let us see what we can do. That's not to say educated guesses aren't alright - in fact, they're more than OK if you can tell us how you came to that conclusion; but if you can't give us a logical, rational explanation on how you came up with your guess, you're better off not posting it.
    Keep public support requests to public channels.
    Problem solving should be public - if someone else comes upon your Problem later, they can look at your thread and see any Solutions that you may be given. There may be reasons for taking something to PM, but unless you're specifically asked to, you should leave it public - taking it to private channels without permission is generally seen as rude.
    Now that you've posted:
    Keep looking for possible Solutions.
    If you find a Solution to your Problem before someone else does, edit your post and tack on the solution, and make the title clear that it's solved. If you say "nevermind, got it" you look like a dick for not posting what you did to fix it, to any future Solution-seeker that may happen to stumble across your thread.

    (Above image copyright 2011 Randall Munroe. Link to source)
    Don't mistake bluntness for rudeness.
    A lot of communications for a lot of people revolve around tact and courtesy - not here. As you can tell by the way this is written, people here to help you solve problems are very seldom here to make you feel warm and fuzzy in doing so. We're not here to offend you, we're just cutting through the unnecessary fluff.
    If you feel someone's being rude, keep cool. If they really are being rude, someone will call them out on it. If they don't and you lose your temper, it's quite possible that whoever you just lost it on was behaving within the community's norms. Most flames are best left to burn themselves out - after, of course, you've checked that they're really flames, and not hidden Solutions to your Problem.
    Don't immediately demand clarification for Solutions you don't understand.
    Yes, you read that right. If you don't understand, you should use the tools you used to try to find your Solution before you posted it (Google, forum search, manuals, logs, etc.) to try to understand the Solution you've been given. If you're still stumped, THEN ask for clarification.
    BAD: "What do you mean 'set SECL to DROT'?"
    GOOD: "I read the manual, but I didn't see anything about DROT under 'SECL'. I did find DROT under 'PRML', and 'ROTA' under 'SECL', though; is it one of these or am I missing something?"
    Don't bump your thread.
    No matter how long it's been, have a bit of patience: no response isn't the same as being ignored, though it may be difficult to tell the difference. Bumping your thread may be seen as a sign of impatience to those that may be trying to help. Also, bear in mind the size of the Earth - even if it's high noon where you live, someone with a potential Solution may be fast asleep at 2 in the morning where they live.
    In Conclusion
    A lot of our ability to give Solutions depends on your ability to provide information. Threads with a lot of useful information are easier to provide Solutions for, whereas Problems with absolutely no information listed are nigh impossible without us having to force the information out of you. By using the above guide, you greatly increase the odds of getting a useful Solution to your Problem, and you may even learn a thing or two in the process.
  18. Like
    EvilJackCarver got a reaction from Original Light in [GUIDE] Getting useful Solutions to your Problems   
    Notes for modstaff in spoiler.
    Preface
    This text was adapted from a document by Eric S. Raymond, titled How to Ask Questions the Smart Way. The full document is available here - the authors of this document are in no way affiliated with G17 Media nor myself, and aren't there to answer your questions about how to get whatever it is you're trying to get working, working.
    Introduction
    If you're reading this, hi there. I suck at smalltalk and making things sound nice, so I'll open with this: In the world of diagnostics, there are a few right ways to get Solutions... and many, many wrong ways. This post is here to hopefully help nudge you toward the right ways, so that you can get the Solutions you want easier.
    Of course, getting a good Solution isn't just on the people helping you solve your Problems - and you're naïve if you think that. A lot of the work needed to solve a Problem falls on you. A vast majority of the time, whether the issue gets solved depends not on the Problem itself, rather what the end user did to troubleshoot and what information they posted in their support threads.
    Depending on how you present your issue and what it may or may not contain, your Problem's thread may get zero replies, or a hundred; it may be solved in an hour, a week, or it may remain an unsolved mystery. This post is here to reduce the odds of that last bit.
    Still with me? Let's begin.
    Before you post:
    Reproduce the issue.
    Try to reproduce the Problem. If your game is crashing, try to duplicate the crash. If you can narrow the crash down to a certain cause, you're much better off with getting a Solution to your Problem, because if you can reliably reproduce the issue and tell us HOW you reproduce it, we're much more likely to be able to see the Problem ourselves.
    Also bear in mind your Problem may just be a fluke. Maybe the stars aligned just wrong. Maybe it just ain't your lucky day. A good rule of thumb is three times - if the Problem appears three times, it isn't "just a fluke".
    Research the issue.
    Before you present your Problem, do a bit of research. Give the manual or readme of whatever's having issues a read - the manual/readme is certainly there for a reason. They may not have a troubleshooting section, but the Problem could be a simple issue with installation, especially if the Problem cropped up right after you installed a mod or reconfigured one.
    If nothing turns up in the manual, it's time to move onto the web. Search the forums for your issue, and look through the results. If you have an error code, search it. There's also a simple method that I use when searching that I refer to as "object-deviation" - as in, "object that's the issue, and deviation from how it normally works". (Side note: This is also a very good way to write your thread's title, as stated in the document linked above.)
    Good example: "GTA5 white police lights".
    If the Problem is an issue with a plugin, it's a good idea to look through your log files - sometimes, the error will be right there in plain sight, especially if it's a configuration issue.
    Note that verbosity isn't necessarily a good thing - a lot of forums will search EVERY word in the search bar, without omitting words like "the" or "are". If it's an issue with a mod, be sure to look through the file comments as well; someone may have had your Problem already and it may be solved already for you.
    If you get nothing on the forums, move on to Google, in quite the same fashion that you searched the forums.
    Sleep on it.
    No, I'm serious. Step away from the Problem for the day/night, regardless of how much you want it fixed here and now. Give it until tomorrow, after you wake up and have a level head, and are all refreshed. It's no use trying to diagnose your Problem while tired; you could easily miss important clues.
    When you post:
    Post in the correct forum. You'd be surprised at how many get moved or locked because they're in the wrong forum.
    Use a descriptive title.
    Some people will read every thread in the support fora, and there's nothing wrong with that. However, most people won't open a thread in a support forum unless the title catches their eye. Most people that look through the support fora will skim the thread titles. Using a descriptive title ensures that your Problem will be seen by someone before they even open the thread. As above, a good convention to use is "object-deviation" - "object of the issue-deviation from normalcy".
    VERY BAD: "GTA doesn't work" - Saying something "doesn't work" is the absolute kiss of death and will very likely cause the thread to be ignored. Saying it "doesn't work" is like a used-car salesman saying a car has wheels - it tells us nothing we don't already know, for if it did work as intended you wouldn't be asking for support. "GTA doesn't work" is not a question, and we're not interested in playing Twenty Questions to pry your actual Problem out of you.
    BAD: "GTA crashes" - It's the bare minimum you can get away with, but you can be more descriptive than that.
    GOOD: "GTA crashes when I drive near the prison" - You have a pretty decent, descriptive title here, saying exactly what's going on - GTA is crashing when you drive near the prison. It doesn't leave what the Problem is for guessing - it's all right there.
    Don't butcher the English language.
    No matter how much of an emergency getting your Problem fixed may seem, THERE IS NO NEED TO USE ALL-CAPITALS IN YOUR TEXT; MOST PEOPLE READ THIS AS SHOUTING. LIKE YOU PROBABLY JUST DID. The only notable exception to not using all-caps is to emphasize A SPECIFIC POINT, in moderation. (writing in all-lowercase is more tolerable, but on some typefaces is very hard to read.) Don't abbreviate unnecessarily, typng n smsspk lik this 2 sv k/s makes u look lik a semi-lit boob.
    If you write like you're a semi-literate boob, you're less likely to receive a Solution and more likely to be a zero-reply thread.
    Describe your problem and your troubleshooting steps.
    At the head of the post, you should re-describe the Problem in further detail and explain what you've tried. If there were any effects on the Problem at all - positive or negative, especially negative - list the effects as well. In doing so, less time is wasted on what you've already done and more can be spent on that which you haven't done.
    Attach relevant logs and configs. If it's an issue with a plugin or an ASI mod, attaching the logs could pin down your Problem to an issue. If it's a configuration issue, attaching your config file could help us point out where you went wrong.
    Leave questions open-ended.
    If you have a question about something, leave it open-ended. Yes-or-no questions get yes-or-no answers; leaving a question open-ended allows room for us to suggest a better way to do whatever it is you're trying to do.
    BAD: "How do I get a RGB car paint colour through a trainer?"
    GOOD: "I'm looking to get an RGB car paint colour from in the game. I'm trying to do it with a trainer but I don't see a way to do it - any suggestions?"
    Note how the way the second example is worded subtly encourages you to suggest something better-suited to the task than the trainer.
    Describe the Symptoms, not wild guesses.
    It's not useful to tell us your wild guesses as to what you think might be happening sans context - if your diagnostic theories were correct, you wouldn't have a Problem to post in the first place. Write down what your Problem's symptoms are and let us see what we can do. That's not to say educated guesses aren't alright - in fact, they're more than OK if you can tell us how you came to that conclusion; but if you can't give us a logical, rational explanation on how you came up with your guess, you're better off not posting it.
    Keep public support requests to public channels.
    Problem solving should be public - if someone else comes upon your Problem later, they can look at your thread and see any Solutions that you may be given. There may be reasons for taking something to PM, but unless you're specifically asked to, you should leave it public - taking it to private channels without permission is generally seen as rude.
    Now that you've posted:
    Keep looking for possible Solutions.
    If you find a Solution to your Problem before someone else does, edit your post and tack on the solution, and make the title clear that it's solved. If you say "nevermind, got it" you look like a dick for not posting what you did to fix it, to any future Solution-seeker that may happen to stumble across your thread.

    (Above image copyright 2011 Randall Munroe. Link to source)
    Don't mistake bluntness for rudeness.
    A lot of communications for a lot of people revolve around tact and courtesy - not here. As you can tell by the way this is written, people here to help you solve problems are very seldom here to make you feel warm and fuzzy in doing so. We're not here to offend you, we're just cutting through the unnecessary fluff.
    If you feel someone's being rude, keep cool. If they really are being rude, someone will call them out on it. If they don't and you lose your temper, it's quite possible that whoever you just lost it on was behaving within the community's norms. Most flames are best left to burn themselves out - after, of course, you've checked that they're really flames, and not hidden Solutions to your Problem.
    Don't immediately demand clarification for Solutions you don't understand.
    Yes, you read that right. If you don't understand, you should use the tools you used to try to find your Solution before you posted it (Google, forum search, manuals, logs, etc.) to try to understand the Solution you've been given. If you're still stumped, THEN ask for clarification.
    BAD: "What do you mean 'set SECL to DROT'?"
    GOOD: "I read the manual, but I didn't see anything about DROT under 'SECL'. I did find DROT under 'PRML', and 'ROTA' under 'SECL', though; is it one of these or am I missing something?"
    Don't bump your thread.
    No matter how long it's been, have a bit of patience: no response isn't the same as being ignored, though it may be difficult to tell the difference. Bumping your thread may be seen as a sign of impatience to those that may be trying to help. Also, bear in mind the size of the Earth - even if it's high noon where you live, someone with a potential Solution may be fast asleep at 2 in the morning where they live.
    In Conclusion
    A lot of our ability to give Solutions depends on your ability to provide information. Threads with a lot of useful information are easier to provide Solutions for, whereas Problems with absolutely no information listed are nigh impossible without us having to force the information out of you. By using the above guide, you greatly increase the odds of getting a useful Solution to your Problem, and you may even learn a thing or two in the process.
  19. Like
    EvilJackCarver got a reaction from Original Light in [GUIDE] Getting useful Solutions to your Problems   
    Notes for modstaff in spoiler.
    Preface
    This text was adapted from a document by Eric S. Raymond, titled How to Ask Questions the Smart Way. The full document is available here - the authors of this document are in no way affiliated with G17 Media nor myself, and aren't there to answer your questions about how to get whatever it is you're trying to get working, working.
    Introduction
    If you're reading this, hi there. I suck at smalltalk and making things sound nice, so I'll open with this: In the world of diagnostics, there are a few right ways to get Solutions... and many, many wrong ways. This post is here to hopefully help nudge you toward the right ways, so that you can get the Solutions you want easier.
    Of course, getting a good Solution isn't just on the people helping you solve your Problems - and you're naïve if you think that. A lot of the work needed to solve a Problem falls on you. A vast majority of the time, whether the issue gets solved depends not on the Problem itself, rather what the end user did to troubleshoot and what information they posted in their support threads.
    Depending on how you present your issue and what it may or may not contain, your Problem's thread may get zero replies, or a hundred; it may be solved in an hour, a week, or it may remain an unsolved mystery. This post is here to reduce the odds of that last bit.
    Still with me? Let's begin.
    Before you post:
    Reproduce the issue.
    Try to reproduce the Problem. If your game is crashing, try to duplicate the crash. If you can narrow the crash down to a certain cause, you're much better off with getting a Solution to your Problem, because if you can reliably reproduce the issue and tell us HOW you reproduce it, we're much more likely to be able to see the Problem ourselves.
    Also bear in mind your Problem may just be a fluke. Maybe the stars aligned just wrong. Maybe it just ain't your lucky day. A good rule of thumb is three times - if the Problem appears three times, it isn't "just a fluke".
    Research the issue.
    Before you present your Problem, do a bit of research. Give the manual or readme of whatever's having issues a read - the manual/readme is certainly there for a reason. They may not have a troubleshooting section, but the Problem could be a simple issue with installation, especially if the Problem cropped up right after you installed a mod or reconfigured one.
    If nothing turns up in the manual, it's time to move onto the web. Search the forums for your issue, and look through the results. If you have an error code, search it. There's also a simple method that I use when searching that I refer to as "object-deviation" - as in, "object that's the issue, and deviation from how it normally works". (Side note: This is also a very good way to write your thread's title, as stated in the document linked above.)
    Good example: "GTA5 white police lights".
    If the Problem is an issue with a plugin, it's a good idea to look through your log files - sometimes, the error will be right there in plain sight, especially if it's a configuration issue.
    Note that verbosity isn't necessarily a good thing - a lot of forums will search EVERY word in the search bar, without omitting words like "the" or "are". If it's an issue with a mod, be sure to look through the file comments as well; someone may have had your Problem already and it may be solved already for you.
    If you get nothing on the forums, move on to Google, in quite the same fashion that you searched the forums.
    Sleep on it.
    No, I'm serious. Step away from the Problem for the day/night, regardless of how much you want it fixed here and now. Give it until tomorrow, after you wake up and have a level head, and are all refreshed. It's no use trying to diagnose your Problem while tired; you could easily miss important clues.
    When you post:
    Post in the correct forum. You'd be surprised at how many get moved or locked because they're in the wrong forum.
    Use a descriptive title.
    Some people will read every thread in the support fora, and there's nothing wrong with that. However, most people won't open a thread in a support forum unless the title catches their eye. Most people that look through the support fora will skim the thread titles. Using a descriptive title ensures that your Problem will be seen by someone before they even open the thread. As above, a good convention to use is "object-deviation" - "object of the issue-deviation from normalcy".
    VERY BAD: "GTA doesn't work" - Saying something "doesn't work" is the absolute kiss of death and will very likely cause the thread to be ignored. Saying it "doesn't work" is like a used-car salesman saying a car has wheels - it tells us nothing we don't already know, for if it did work as intended you wouldn't be asking for support. "GTA doesn't work" is not a question, and we're not interested in playing Twenty Questions to pry your actual Problem out of you.
    BAD: "GTA crashes" - It's the bare minimum you can get away with, but you can be more descriptive than that.
    GOOD: "GTA crashes when I drive near the prison" - You have a pretty decent, descriptive title here, saying exactly what's going on - GTA is crashing when you drive near the prison. It doesn't leave what the Problem is for guessing - it's all right there.
    Don't butcher the English language.
    No matter how much of an emergency getting your Problem fixed may seem, THERE IS NO NEED TO USE ALL-CAPITALS IN YOUR TEXT; MOST PEOPLE READ THIS AS SHOUTING. LIKE YOU PROBABLY JUST DID. The only notable exception to not using all-caps is to emphasize A SPECIFIC POINT, in moderation. (writing in all-lowercase is more tolerable, but on some typefaces is very hard to read.) Don't abbreviate unnecessarily, typng n smsspk lik this 2 sv k/s makes u look lik a semi-lit boob.
    If you write like you're a semi-literate boob, you're less likely to receive a Solution and more likely to be a zero-reply thread.
    Describe your problem and your troubleshooting steps.
    At the head of the post, you should re-describe the Problem in further detail and explain what you've tried. If there were any effects on the Problem at all - positive or negative, especially negative - list the effects as well. In doing so, less time is wasted on what you've already done and more can be spent on that which you haven't done.
    Attach relevant logs and configs. If it's an issue with a plugin or an ASI mod, attaching the logs could pin down your Problem to an issue. If it's a configuration issue, attaching your config file could help us point out where you went wrong.
    Leave questions open-ended.
    If you have a question about something, leave it open-ended. Yes-or-no questions get yes-or-no answers; leaving a question open-ended allows room for us to suggest a better way to do whatever it is you're trying to do.
    BAD: "How do I get a RGB car paint colour through a trainer?"
    GOOD: "I'm looking to get an RGB car paint colour from in the game. I'm trying to do it with a trainer but I don't see a way to do it - any suggestions?"
    Note how the way the second example is worded subtly encourages you to suggest something better-suited to the task than the trainer.
    Describe the Symptoms, not wild guesses.
    It's not useful to tell us your wild guesses as to what you think might be happening sans context - if your diagnostic theories were correct, you wouldn't have a Problem to post in the first place. Write down what your Problem's symptoms are and let us see what we can do. That's not to say educated guesses aren't alright - in fact, they're more than OK if you can tell us how you came to that conclusion; but if you can't give us a logical, rational explanation on how you came up with your guess, you're better off not posting it.
    Keep public support requests to public channels.
    Problem solving should be public - if someone else comes upon your Problem later, they can look at your thread and see any Solutions that you may be given. There may be reasons for taking something to PM, but unless you're specifically asked to, you should leave it public - taking it to private channels without permission is generally seen as rude.
    Now that you've posted:
    Keep looking for possible Solutions.
    If you find a Solution to your Problem before someone else does, edit your post and tack on the solution, and make the title clear that it's solved. If you say "nevermind, got it" you look like a dick for not posting what you did to fix it, to any future Solution-seeker that may happen to stumble across your thread.

    (Above image copyright 2011 Randall Munroe. Link to source)
    Don't mistake bluntness for rudeness.
    A lot of communications for a lot of people revolve around tact and courtesy - not here. As you can tell by the way this is written, people here to help you solve problems are very seldom here to make you feel warm and fuzzy in doing so. We're not here to offend you, we're just cutting through the unnecessary fluff.
    If you feel someone's being rude, keep cool. If they really are being rude, someone will call them out on it. If they don't and you lose your temper, it's quite possible that whoever you just lost it on was behaving within the community's norms. Most flames are best left to burn themselves out - after, of course, you've checked that they're really flames, and not hidden Solutions to your Problem.
    Don't immediately demand clarification for Solutions you don't understand.
    Yes, you read that right. If you don't understand, you should use the tools you used to try to find your Solution before you posted it (Google, forum search, manuals, logs, etc.) to try to understand the Solution you've been given. If you're still stumped, THEN ask for clarification.
    BAD: "What do you mean 'set SECL to DROT'?"
    GOOD: "I read the manual, but I didn't see anything about DROT under 'SECL'. I did find DROT under 'PRML', and 'ROTA' under 'SECL', though; is it one of these or am I missing something?"
    Don't bump your thread.
    No matter how long it's been, have a bit of patience: no response isn't the same as being ignored, though it may be difficult to tell the difference. Bumping your thread may be seen as a sign of impatience to those that may be trying to help. Also, bear in mind the size of the Earth - even if it's high noon where you live, someone with a potential Solution may be fast asleep at 2 in the morning where they live.
    In Conclusion
    A lot of our ability to give Solutions depends on your ability to provide information. Threads with a lot of useful information are easier to provide Solutions for, whereas Problems with absolutely no information listed are nigh impossible without us having to force the information out of you. By using the above guide, you greatly increase the odds of getting a useful Solution to your Problem, and you may even learn a thing or two in the process.
  20. Like
    EvilJackCarver got a reaction from Starmix in whatc is keybind for LSPDFR   
    LSPDFR's default keybindings can be found on the FAQ, about two-thirds of the way down, in a spoiler box.
  21. Like
    EvilJackCarver got a reaction from Animefan162a in Requesting a couple of clean templates.   
    It's possible, but tedious. What you could do is use a white layer (hidden until you go to test), and have another layer you colour on. It's what I (and probably a good majority here) have done. To show off an example (which is a texture I edited for personal use to make an in-joke)...

    That's how I worked on it - sign_1 is the base paint layer (and the base template that I started using), Layer 1 is the cover-up colours you see by the mirrors. I worked on it with the template visible, and when the time came to export it as .PNG, I ticked the base paint colour (or, in this case, sign_1) to be visible and went from there.
    This isn't to say that there aren't other ways of doing things - whiting out the template and colouring inside the lines is a perfectly valid way, albeit one that might earn you some funny looks - but a lot of people do it this way for a reason, so that you still have the (imprecise) template polys to line everything up on.
    Also, a lot of UV mapping - especially in GTA IV on the older Chargers - is imprecise. What I mean by that is, as you get close to the dividing line between two panels on the livery - say, the side view and the back bumper - one of them inevitably starts distorting, and won't exactly be true to the poly grid shown on the template. You also have to account for the outline that's there around the entire outside of the vehicle that you can't see - it may or may not be mapped. In a lot of the older cases (gonna pick on one of the old HSD Chargers here) it IS mapped, so you have a pixel more than you can see on the black-outline template.
     
  22. Like
    EvilJackCarver got a reaction from Animefan162a in Requesting a couple of clean templates.   
    Easy way to get a black-and-white template out of a colour one: Grayscale the colour one, add a layer of 50% grey on colour dodge, duplicate the grey layer as necessary.

    That said, generally speaking it's easier to tell what bits and bobs of a gradiented template are where on the model without having to look at the model; a lot of modellers tend to use a locator gradient (I never learned the proper term) for this very reason.
  23. Like
    EvilJackCarver reacted to Animefan162a in Requesting a couple of clean templates.   
    I'm looking at the templates right here and ironically the author provided a template for every vehicle in the pack except the 2013 Taurus, just my luck. I guess I'll message them and ask. Thanks a bunch for your help, I appreciate it!
  24. Like
    EvilJackCarver got a reaction from 11john11 in Setup Wars! Show us your spot!   
    My organised mess I call a desk.
    You should've seen it a year ago.
  25. Like
    EvilJackCarver got a reaction from Prophet in Setup Wars! Show us your spot!   
    Hell, why not.
    Fair warning, my desk is a mess.
     
×