Help with RPG inventory system (solved) Thanks!

[Tresky]

"Hey look at my completly broken and rusty car! Could you please put some new shiny rims on it? I'll get the car fix later, but now I just need those rims!"

LOL! Ricers!
http://i9.photobucket.com/albums/a95/rehab_/Ricer/ricer.jpg

[Pikmeir]

"Hey look at my completly broken and rusty car! Could you please put some new shiny rims on it? I'll get the car fix later, but now I just need those rims!"
That pretty much sums it up for me, I wish you good luck! 

If I knew as much as you do, I'd at least be a bit more helpful to people who are new.
"Hey, I've learned programming for 10 years. Good luck getting to where I am."
That pretty much sums it up for me.

[mastodona7x]

Go easy on him guys, I'm a fellow newbie to C++/sfml but always found the people on here really nice and helpful!! And in the IRC chat too...got all my problems fixed without resorting to insults Hope you get your game going it looks like turning into a nice little project to me

[Pikmeir]

I played around with it for several more hours and finally solved it myself. I think it might be a problem with SFML. I tried everything I could think of and was suggested to me, changed the arrays to vectors, and changed the entire system to use an array of integers that represent different items. Everything gave the same outcome.

So my conclusion is this: this might be a bug in SFML. SFML might get confused or something if the textures are below a certain size, or maybe when switching textures via setTexture() that are different sizes? I'm not sure, since I haven't read the SFML source. Anyway it's safe to say that my code should've worked were this not the issue.

Originally invEmpty was a texture that was 5 by 5 pixels in size. When I simply changed the size to 43 by 43 (the same as the other items), the problem disappeared. I'm pretty sure this is therefore a bug in SFML, and not the result of my stupid programming (although I know my programming is pretty stupid).

[eXpl0it3r]

I actually didn't wanted to write here anything anymore, but here I go anyways...

If I knew as much as you do, I'd at least be a bit more helpful to people who are new.
"Hey, I've learned programming for 10 years. Good luck getting to where I am."
That pretty much sums it up for me.

Okay, it seems you didn't understand at all what my analogy should have told you. Here again in English: First, if you program something, then don't do it just for 'temporary' cause and specially when other people with more experience tell you to change it, since it may ivoke side effects.
Second, if people tell you to go study and read about certain topics specially basics ones, then do so and don't expect that the knowledge will suddendly fall from the sky. Ignoring such adivce is really ignorant and tells the people willing to help that you're not willing to learn and thus the whole process of helping seems to be for nothing.

So my conclusion is this: this might be a bug in SFML. SFML might get confused or something if the textures are below a certain size, or maybe when switching textures via setTexture() that are different sizes? I'm not sure, since I haven't read the SFML source. Anyway it's safe to say that my code should've worked were this not the issue.

Originally invEmpty was a texture that was 5 by 5 pixels in size. When I simply changed the size to 43 by 43 (the same as the other items), the problem disappeared. I'm pretty sure this is therefore a bug in SFML, and not the result of my stupid programming (although I know my programming is pretty stupid).

Assuming something is defect in someone elses code without even completly understanding what's happening in its own code is just wrong.

If you had read the documentation (or looked at the functions signatures probably provided by your IDE) you could have figured out your problem way earlier and yes it's all "the result of my stupid programming". Since one would never relay on some size of a sprite/texture to figure out the current state.

From the documentation:

void sf::Sprite::setTexture (const Texture & texture, bool resetRect = false)      
Change the source texture of the sprite.

The texture argument refers to a texture that must exist as long as the sprite uses it. Indeed, the sprite doesn't store its own copy of the texture, but rather keeps a pointer to the one that you passed to this function. If the source texture is destroyed and the sprite tries to use it, the behaviour is undefined. If resetRect is true, the TextureRect property of the sprite is automatically adjusted to the size of the new texture. If it is false, the texture rect is left unchanged.

Parameters:

• texture   New      texture
• resetRect      Should the texture rect be reset to the size of the new texture?

If you didn't get what this is all about, here again in plain text: You have to use sprite.setTexture(texture, true); so the rectangle gets reset.

Keep in mind this doesn't mean that everything is solved for sure (since you got so much stuff around that could go wrong, e.g. the removal of item 2 or 3 doesn't work afaik), but it will at least get rid of the (in your opinion) main problem.

And again: Read a book about C++ & RTFM.

[Pikmeir]

Thanks for finally helping me!
After reading about how textures work in your post (quoted from Laurent), it all makes sense now. Although I solved it by switching my code around, I'll keep this in mind for the next time.

But it is interesting how you must've known this all along, but refused to help someone who knew less than you simply because "I know less than you so I have to learn everything by myself, without anyone's help."

Well, how about if you opened up a book when you were new to programming, and the book only said, "learn it yourself, cuz that's how I did it." Maybe this is a bit exaggerated, and I guess you'll disagree.

Anyway thanks though. I guess there is a purpose for slightly rude, yet experienced programmers like you in the help forums.

I should add that the "thank you" here is real though. I do appreciate you finally giving me a helpful answer, and I really will remember it to not make the same mistakes in the future. But that's how I learn, by trying my best and making mistakes and fixing them, and not being afraid to ask people more experienced than me for help.

[eXpl0it3r]

No I didn't know the answer at all until a few minutes before I posted the other post. And thats because I sat down took your code removed everything that was not needed and step by step added a few things. Thos whole process costed me around 30min. This wohle thing shouldn't have been my work to do but yours. I know your spend quite a lot of time figuring things out, but with minimizing and then slowly progressing you would have found the problem too. But you insisted on keeping your functions and weren't willing to make everything simpler...

I still don't see where I wasn't helping. I pointed out many flaws and errors and just because I didn't sit down for 30 or longer to take apart your messy code back then, you consider me as not willing to help?

Trail & error is always present but there are diffrent angels to it. If someone just throws code at others and expect them to reprogram everything fir them then this is a bad angle, it would be better to follow the advice given by others and spend more time on thinking on it's on and comtinuesly sharing the progress.

And if you're lacking in basic knowledge things that SFML requires then you should maybe refresh your memory on your own or go to a diffrent forum specific to basic C++.

[Pikmeir]

I never expected anyone to reprogram everything. My original post only had a few lines which I shortened as much as possible to illustrate the problem I was getting, and reading it again now I can see that my original problem could've been fixed through just looking over the first post - had I known exactly how SFML textures worked. I didn't know exactly how they worked, so I came here for help.

I will say that the suggestions you first told me I did implement and fix (although I didn't upload it here to avoid repetitively posting my code), but my original problem was still there. When I told you that, you just said my code was horrible (even though I apologized in advance for being new), pointed out unrelated issues that weren't causing my actual problem, and because you seem to have OCD insisted I fixed those before doing anything.

And if you're lacking in basic knowledge things that SFML requires then you should maybe refresh your memory on your own or go to a diffrent forum specific to basic C++.

So basically you're saying, "This forum is for experienced C++ and SFML users only. Get out."
It's quite tongue-in-cheek, but I understand. Thanks for eventually helping me solve the problem, but I'm not sure I'd do it again in exchange for having people push me away from their "help forum" for being inexperienced. I probably will take your advice and stay away from this forum from now on, especially after the welcome I've gotten trying to post my questions here.

[eXpl0it3r]

...and because you seem to have OCD...

What a creative insult.

I never expected anyone to reprogram everything. My original post only had a few lines which I shortened as much as possible to illustrate the problem I was getting.

How else do you expect people to understand your code? I mean if it were nicely laid out it would habe been easy to read and understand but having global objects and a bit more complex machanism there's no other way than to recreate everything to first fully understand what's happening and second to find the bugs.

I will say that the suggestions you first told me I did implement and fix (although I didn't upload it here to avoid repetitively posting my code), but my original problem was still there.

I'm not quite sure what you're refering to, but you probably should have upload that code, so it would've maybe been easier to understand your code.

When I told you that, you just said my code was horrible (even though I apologized in advance for being new), pointed out unrelated issues that weren't causing my actual problem, and because you seem to have OCD insisted I fixed those before doing anything.

That's the problem. When your code is messy it's hard to understand it without having to go through everything and the possibility is quite high that something along the line was causing it.
I gave up helping you because I didn't want to spend my time looking through your messy code but I would have looked through it if you just cleaned it up. And figure that at the end I now even spend my time to go through your code and check back here to read some of your nicely insults.

So basically you're saying, "This forum is for experienced C++ and SFML users only. Get out."
It's quite tongue-in-cheek, but I understand. Thanks for eventually helping me solve the problem, but I'm not sure I'd do it again in exchange for having people push me away from their "help forum" for being inexperienced. I probably will take your advice and stay away from this forum from now on, especially after the welcome I've gotten trying to post my questions here.

Feel free to turn my words around.
What I'm saying is that we're happy to help in most of all problems, but fact is that SFML shouldn't be the first thing anyone starts to program with. There are many basics in C++ that one just have to learn first before digging into a library. So if we notice that there's a lack of knowledge we point that out and since this forum is about SFML and not how to learn C++ we often don't feel like explaining in depth what a good book could tell you even better.

Have fun!

[Tank]

Pikmeier, a warm welcome to the SFML forum, where even newbies get appropriate help!

Seriously, there's a big misunderstanding by newbies, very often. You stated that you're new to programming (C++) and SFML. That implies you will at least have problems with a) programming C++ in general, b) understanding C++ code design principles and c) using SFML (together with a and b!).

Up to now, you've probably been able to build some programs that "just run" – *somehow*, but unfortunately you're running into a big problem now, which is often the result of tens or hundreds of other small problems.

So you post in this forum, describe your problem, and because you don't really know where it comes from (because you actually don't have a clue what everything does in detail, or you got lost because of a bad code design), you paste a lot of source code.

That's the first sign for an experienced user that someone is having *problems with basics*, if it's C++ programming or using SFML.

There's really no insulting intended, but imagine you've been through all of that, i.e. you learned your stuff and are now in a position to provide help. Nobody learns from getting replies in a forum, that's just for specific problems that you can't solve. Instead you read bundled information, like books, SFML tutorials or even source code of other projects.

But one thing is *really* for sure: When an experienced user throws "RTFM" or "Read a C++ book, learn the basics!" at you, then chances are high that she or he is, guess what, just right.

On IRC a lot of newbies come and go, a lot are asking very basic questions which can be solved by giving them a link to SFML's Doxygen documentation. And often we hear something like "Oh thanks, I haven't yet seen that docs!". You know what that implies? It implies that the proper user did not click on "Documentation" on the website. And especially those users often yell "Why can't you just help me instead of telling me to read myself?"..

So, the main reason why you're getting "RTFM" is that it's a waste of time to explain things to you that are explained in books/articles already, you just have to read them.

Besides of that, also very common, you were able to sort out your problem yourself by investing some more thinking and time into it. *That's* how you learn stuff, not by asking for the fixed source code.

So please don't feel insulted when people tell you to learn your stuff, there's a reason behind it. If you've got *specific* problems we're for sure happy to help you, or general questions about game design etc.

And again, welcome!

[Pikmeir]

Pikmeier, a warm welcome to the SFML forum, where even newbies get appropriate help!

Thanks Tank.
In this situation, I jumped in here after trying to solve it myself for 7 consecutive days unsuccessfully; I couldn't find anywhere in the documentation myself why it wasn't working. I thought it might be an update issue, so I was looking for something like an update() function within the code for several days but I couldn't find one.

Anyway with that said, do you have a recommended C++ book? I've been using the cprogramming.com and learncpp.com tutorials, and have pretty much finished them all and am looking for an actual book to learn more from - by "more" I mean the same things all over again, but from another perspective.

[mastodona7x]

I just borrowed "C++ for game programmers" by M J Dickheiser from the libray, I too started with learncpp.com and this book goes over some of that stuff in far more depth and all from the point of view of developing games...seems interesting (if a little bit daunting)...I also borrowed "AI game engine programming" which looks good too and has real world examples and AI ideas/code snippets for all different game genres (racing, RTS, RPG, FPS etc etc etc) which makes it quite an interesting read so far.