Feb 18 2014, 3:24 pm
|
|
Lugia319
 |
I don't mind rips. I mind liars that say they're gonna originalize rips and have no idea what they're doing.
|
True, but I think if they just steal codes and make a game out of them is sick since that's someone's work and time. If you rip someone's work, then you're slapping them in the face with all their time putting the work into the codes.
I hate that too, but not all rips are copies, really. Like, I copied Mitadake High without using any source code of any kind because for one, it's basic and easy coding. But after a few weeks of it being up..I hated the fact it looks just like Mitadake High. The point of it was the game-play was suppose to feel like RPG Maker Horror Games, but eh...It didn't turn out the way I wanted it. So a new game design is taking place. ^_^ The settings would be different, along with the game since the game-play would be awesome. | |
The unfortunate thing really is that there's a fair amount of good source code available on the site. Maybe it's not always the best code, but surely it is a lot better than that god-awful list of variables.
Having hp and maxhp separate is one thing, this is worse:
Utiger=0Also note that despite expecting "dog" to come after "Udog" and "Odog", they wrote "dogs". This is terrible. It's hard enough to keep your code organized when you are just starting out, must be impossible if you are trying to learn using a rip like this... Audio freak XD wrote: True, but I think if they just steal codes and make a game out of them is sick since that's someone's work and time. If you rip someone's work, then you're slapping them in the face with all their time putting the work into the codes. As far as I know the ripping craze came from developers releasing their source code willingly. Anyone who actually steals resources is obviously a turd. | |
Like I noted in the original post, you can compress A LOT of variables using strings and lists.
mob/var I think I just took away about 70 lines right there. Plus it's easier to loop through lists when you're looking for a something than to try and remember if you've defined the variable somewhere. Also COMMENTS ON CODE SAVE LIVES. If you're not commenting your code as you write it, you're doing it wrong. How are you learning from poorly documented code? | |
Well, I'd probably argue you only comment that which is too complex to sight-read by names.
Not to mention that much of the issue of those variables is probably not their number, but the fact they represent concepts that should've been factored into other datums entirely, depending on how they were used. This is much of the problem of these kinds of topics, you've taken a spot check of code that's not necessarily telling, and you're making some fairly blanket assertions on it. No-one's code gets better out of this. Just different. | |
Looking at the advertisement section on these forums, I smack my face against a wall when I see yet another "I want to make a rip, it will be different!". What happened to being original :\
| |
It's fine in my opinion for a giant list of variables. However, it's more simple to see it as a list instead of boom, boom, boom...thousands of variables when it's not needed.
Beginners are taught zero list variables when they first begin coding, but they also don't understand that there are variables and switch variables. Example: mob/var/list/characters=list("Mia","Kia")//variable They also have no idea that they can use 'text' to replace the no and yes numbers, such as the first 'me' variable. Example: mob Or: obj But now they have too many if statements that'll just make things seem too much. obj So, I hope newbies see these examples on the tips...it's simple procedure, and would make the code seem organize and have less lines. | |
Except that they're not being taught, they're reading rips.
| |
Agreed.
They aren't being taught, they're just seeing common bad habits that previous beginners who taught themselves have done. When they see a list like that, they are overly-excited to see that codes are given to them, so then they quickly copy and paste or retype it and pretend that they're learning about it. However, they read the 'rip' not what it says. Example: mob There reaction, "WTF, WHY IS IT SHOWING ME NOTHING? WTFFFFF!!!!" Why don't they know the mistake? Because they don't take time to read the code. But in words, you're saying... For those objects who are mobs that are in the world. If myself is this object, then stop functioning(the area that gone wrong). Add all objects to the players list. View player's list, but at a completely clean list, then see player's list. When pressed cancel, stop functioning; however, if clicked on someone, a message appears stating that you see them! First of all, replace return with continue to bypass stuff. Second of all, usr causes problems with CPU when not coded in the right spot. You're making Dream Seeker do more work than it should since src means you exactly, and usr means the other person interacting with you. | |
I'm not sure if you're defending rips as a resource to learn from or not. I'm gonna say you are, and remind you that we have tons of other resources in the form of demos and libraries.
| |
Audio freak XD wrote:
Second of all, usr causes problems with CPU when not coded in the right spot. You're making Dream Seeker do more work than it should since src means you exactly, and usr means the other person interacting with you. Alright now just calm down you are not making sense! That's not a good description of src and usr. Also, I have no idea what this CPU hog thing is all about. Generally the problem with putting usr in procs is that the proc ends up getting called with an undesirable or function-breaking value for usr...which is often null. This results in strange behavior and possibly errors/crashes, but not CPU hog | |
It's just a random drawing of mine, here's a bigger version:
 | |
Re-read, it's stated that they don't learn from rips...
It also says the reason why they don't learn the codes is because they don't read what it says...:/ | |
You sure that 'usr' doesn't cause CPU problems?
I think it could. | |
Audio freak XD wrote:
Re-read, it's stated that they don't learn from rips... Re-read: You're suggesting that they're trying to learn from rips. As for src vs usr mob test1 uses .007 CPU and test2 uses .005 CPU. For So yes, it uses slightly more but it's really not noticeable until you're in the tens of thousands of calls. On top of that, these calls have to be done simultaneously (on the call stack) for it to be of any effect. (Remember that you "get your memory back" when procs resolve) So yeah, it *COULD* cause a problem... if you have tens of thousands of these calls happening at the same time, which I SERIOUSLY doubt is gonna happen. So usr abuse away, as long as you're not using usr where you're supposed to use src. | |
Lugia319 wrote:
Audio freak XD wrote: > mob test1 uses .007 CPU and test2 uses .005 CPU. For So yes, it uses slightly more but it's really not noticeable until you're in the tens of thousands of calls. On top of that, these calls have to be done simultaneously (on the call stack) for it to be of any effect. (Remember that you "get your memory back" when procs resolve) Thank you, been looking for some facts on the matter. I understand how usr & src can differ as far as WHO/WHAT the entity is but every time I ask what would be the actual difference in using it if usr/src are the same entity. Now I know. (I have switched to using src when they are the same anyways but I am the curious type and it was driving me nuts that nobody could tell me.) | |
The issue mostly regards code re-use and how brittle usr is.
Just because your calling context at the moment is such that usr and src are interchangeable, doesn't mean it will be in all cases you want to use that procedure. The difference is conceptual, they mean different things and that dictates their use accordingly. It's much of that same as using the : operator very liberally to resolve member variables as opposed to a type-cast. They both work in a number of cases, but they are conceptually different and that difference is important for re-use, how brittle code might be etc. | |