C++ Question Pointer Problems

[escapetomsfate]

So the bullets/shells/whatever never actually get destroyed? That's bad. The more you fire, the more vessels get added to the scenario and the more Orbiter will slow down until it becomes unusable. You have to delete the things sometime.

And if your code crashes whenever a bullet/shell/whatever hits the ground, or if it fills the scenario with old and undeleted bullet objects, no one will use your framework.

Once I get the collision stuff sorted out, I will make it delete them after a set amount of time.

 

[Quick_Nick]

Just had a thought... if you call explode anytime your weapon is below a certain altitude, explode(i) will begin to be called as often as it possibly can. You then have it trying to InsertMesh every single chance it gets... right? You likely need to check not only if it is below the explosion altitude, but also if it has already been exploded before... right?
I could be WAY off here. I'm no C++ expert, so please let me know. :lol:

 

[escapetomsfate]

Just had a thought... if you call explode anytime your weapon is below a certain altitude, explode(i) will begin to be called as often as it possibly can. You then have it trying to InsertMesh every single chance it gets... right? You likely need to check not only if it is below the explosion altitude, but also if it has already been exploded before... right?
I could be WAY off here. I'm no C++ expert, so please let me know. :lol:

Noope, you're spot on I'll put in a exploded bool and make it check first.... might just work.... Thanks

 

[tblaxland]

Also, I want a seperate Fired Vector, so that I can keep track of each fired weapon by it's class.

In which case it needs to be a static member. If it is non-static, each weapon (not class of weapon, each weapon) will have its own Fired vector with exactly one instance in it.

To be honest, I'm trying to make a sort of framework for combat, so all the hard stuff is already done for a developer.

To be honest, it is quite a poor way of going about it. One worthy goal of object oriented programming is to make your object's interfaces as simple* as possible. If you WeaponClassList doesn't need to know how to explode() your Weapons (and it doesn't, if it is just based on altitude), then don't do it. Your Weapons are capable autonomous operation, so give them that autonomy. It will make your code more readable and more maintainable, two critical items if you wish to develop a successful "framework".

* Maybe simple is not quite the right word. Apply Occam's Razor to your interfaces.

 

[escapetomsfate]

I suppose a project this complex is a bit too advanced for me. Like all other failed projects that I've attempted, it seemed much more straightforward as an idea in my head.

Still, thanks for your help, all of you

 

[Quick_Nick]

I suppose a project this complex is a bit too advanced for me. Like all other failed projects that I've attempted, it seemed much more straightforward as an idea in my head.

Still, thanks for your help, all of you

So... did it work?

 

[escapetomsfate]

The explosion mesh spawns, yes I used a mushroom cloud mesh from google warehouse, looked pretty cool

 

[Quick_Nick]

The explosion mesh spawns, yes I used a mushroom cloud mesh from google warehouse, looked pretty cool

I'm guessing no CTDs then?!

 

[tblaxland]

I suppose a project this complex is a bit too advanced for me. Like all other failed projects that I've attempted, it seemed much more straightforward as an idea in my head.

Still, thanks for your help, all of you

Sorry, I hope I didn't discourage you. Just offering some friendly advice. Perhaps I can offer some more? If you feel it is too advanced for you, come back and try it again later when you have learnt some more. I am on my third attempt* at AttitudeMFD v4 (I might even get it this time) but the goal of getting it written has kept me motivated to further my programming knowledge. One thing that has helped me a lot in developing my more recent addons are Class Diagrams: http://en.wikipedia.org/wiki/Class_diagram. I use Visual Paradigm for UML Community Edition for mine, but it can be a little overwhelming. Perhaps there is something else out there which is simpler.

EDIT: * The other two were aborted because I found better ways, principally related to the object model. Similar sorts of issues to what you are dealing with here.

 

[escapetomsfate]

Sorry, I hope I didn't discourage you. Just offering some friendly advice.

Not at all, that advice is much welcomed. I thought that even if I do get collision working well, I'd still have to do things like manage individual vessel's weapons and damage etc, which would be really hard without editing the SDK (At least from what I can think of).

Perhaps I can offer some more? If you feel it is too advanced for you, come back and try it again later when you have learnt some more. I am on my third attempt* at AttitudeMFD v4 (I might even get it this time) but the goal of getting it written has kept me motivated to further my programming knowledge. One thing that has helped me a lot in developing my more recent addons are Class Diagrams: http://en.wikipedia.org/wiki/Class_diagram. I use Visual Paradigm for UML Community Edition for mine, but it can be a little overwhelming. Perhaps there is something else out there which is simpler.

EDIT: * The other two were aborted because I found better ways, principally related to the object model. Similar sorts of issues to what you are dealing with here.

Good luck with that Please keep at it, AttitudeMFD is awesome. A version that's even better would be phenomenal

 

[escapetomsfate]

Woohoo! Fixed Ground explosions and vessel-weapon collision!

The other day, I tried changing around the code a bit with a fresh mind, and actually managed to do it

Also made two weapons for it - Little Boy nuclear bomb and a missile.

Dropping the bomb -


And the resulting explosion -

I'm guessing no CTDs then?!

No! I've fixed all bugs (That I've come across)

Will upload it soon.

Woohoo!