I haven't used this sdk yet, but some standard trouble shooting techniques can be tried after you've tried all of the more specific suggestions. These apply to most coding type problems.
1) Verify the build environment:
Rebuild everything with NO changes. Sometimes file perms, dates or other meta data can be hosed. And, since this is windoze, there is always the possibility that it stomped on something important. If you can't make a pristine system work, then you probably can't make your
hacks work either.
2) Verify that your changes are actually being incorporated into the system. Find the simplest noticable change you can make. If possible, change a simple string: "BullPup" --> ">>BullPup<<" There may not always be an obvious or convenient thing like this. But it should be possible to write to the console some way: (made up syntax, but you get the idea) console.printf("Eh-oh, console.");
If your build seems to work and you don't get the message, then you'll need to do some API/SDK specific troubleshooting that I amn't familiar with. This could include things like dir permissions, environment vars, config parameters and the ever present chance that windoze is hozed or has hozed something. Reboot, reset, reinstall, sacrifice a chicken. You've already sacrificed $ and time.
But you'll know something is wrong with the system somewhere... this does not mean your code isn't b0rked, too. But you'll need to fix the former before you can check the latter.
3) Someone else mentioned this, but it bears repeating: pick the class that is closest to what you want. Modify BullPup rather than something farther up the family tree.
(I haven't seen the hierarchy yet, but it could be something like this.
this is off the top of my head. flames > /dev/null)
Code:
Actor
... a bunch of stuff
gun
+--- pistol
+--- rifle
+--- Bolt action
+--- Automatic
+--- SMG/AR, etc
+--- AK
+--- BullPup
| +--- My bp sub-class <<<-- yes
+--- My foolish new smg sub-class <<<-- NO!
+--- My way-too-much-work-pup <<<-- NO!
Given this, and your problem, BullPup makes the most sense.
This means that your class only needs to implement the differences from BP. You can do the NO line, but don't. You'll get cooties and lockjaw. And CTS. Coders (the good ones) are lazy and want to minimize changes. This also happens to be very, very good programming practice as well. Fewer changes, fewer places bugs can be added. Program by differences.
Tim Sweeney worked hard designing a beautiful game coding system, which includes at the least his own C-like OOPL with async and parallel features. And a deep, well thought out and designed object hierarchy. Don't kick him in the nuts
by not using it!
4) Implement your changes incrementally. This way you only need to worry about one change at a time, and if things break, it can only be in the new code just added. If you make
N changes, it can more like
N^2 harder since changes can interact.
5) Comment your changes. It'll help you when you sober up and could be useful to others who
steal your code.
6) Take a break. Relax. Breathe. In thru the nose, out thru the mouth.
And then:
YouTube - Man destroys computer
Advanced:
Experienced programmers recognize the futility of it all and go straight to a therapist by way of step 6.
Nothing is too simple to do wrong.
When all else fails, check the plug.
Growing a pony-tail can increase your coding skills by up to 40%.
Beards work, too:
This does not help:
