Welcome!

Join our community of MMO enthusiasts and game developers! By registering, you'll gain access to discussions on the latest developments in MMO server files and collaborate with like-minded individuals. Join us today and unlock the potential of MMO server development!

Join Today!

Errors - Can Anyone Look Into This?

Status
Not open for further replies.
Newbie Spellweaver
Joined
Feb 17, 2015
Messages
47
Reaction score
6
Isn't everyone Ducking annoyed at how when you make a script then try to run it you get several errors? That happened to me when I was testing out this guy's script called . I hosted it through XAMPP and the index page had many errors. Then I hosted it through (my favorite web hosting service) but still same errors.

So I edited the database files and the connections were working, but when I went into the config files, the text weren't separated from html to php. Can anyone try and run the game on their host to see if they have the same issue? I can't even log into the game!

(I am new - new but not new to forums)
 
☮TAKU????
Loyal Member
Joined
Nov 16, 2009
Messages
866
Reaction score
580
What exactly are you trying todo? The information you have given so far is not enough to properly track your problem.
 
Joined
Jun 8, 2007
Messages
1,985
Reaction score
490
When I make a script and run it, I usually understand what the errors are if I get any, laugh at myself for making a mistake, then fix the errors. Many programmers have been getting annoyed at errors which are hard to diagnose for quite some time. As a result, there are programming paradigms, styles, good practices, and guides on documenting code with the intent on making errors easier to diagnose. The more complex the beast, the more necessary it is to follow good practices and obsessively document your code. Many complex systems even have their own section of the application code dedicated to debugging- that is, a built-in debugger.

Unit-testing is important for complex systems. If you make changes to a core of an application which is providing an API for the rest of the application, you want to have a strong unit-testing system so that you know the changes you make to the API will not break the rest of the application... And changes to the API usually do break many parts of the system. With unit-testing in place, that's no big deal. You run the build procedure after making a change, see the error caused by the change, and go back. The build procedure should run 100's of unit-tests on a medium-to-large API. A developer of such a system would be quite naive not to have implemented some form of unit-testing for this situation. I mean, imagine making a change to one line, than making a test, refreshing.. making another test, refreshing.. etc, 100 times? A unit-test is the only way to go when you reach that point. The good thing about unit-tests, is once you reach the point of no return, you can still implement unit-tests.. You don't have to start coding from day-1 with unit tests in place.. It's not like, "Oh, I forgot to use [insert good practice here] on this project, so I have to redo the whole thing or just live with my mistake.."

Separation of responsibilities is important, too. You don't want to keep PHP code in the same file as HTML code, even though that's a feature of PHP which really helped the language gain popularity by dragging web-designers into the programming industry... It's still a bad idea. I would assume that a system becomes exponentially harder to debug as the complexity of that system increases. Mixing the client-side logic with the server-side logic doesn't help.

For small applications, it seems silly to document every single step, create a build procedure, run 10's of unit tests, and the like. But you don't want to get caught napping when building complex beasts.. You want to take the time to make your code as easy to debug as possible from day-0, forward. Take the extra time to think about what you're getting yourself into before you start a big project.
 
Last edited:
• ♠️​ ♦️ ♣️ ​♥️ •
Joined
Mar 25, 2012
Messages
909
Reaction score
464
When I make a script and run it, I usually understand what the errors are if I get any, laugh at myself for making a mistake, then fix the errors. Many programmers have been getting annoyed at errors which are hard to diagnose for quite some time. As a result, there are programming paradigms, styles, good practices, and guides on documenting code with the intent on making errors easier to diagnose. The more complex the beast, the more necessary it is to follow good practices and obsessively document your code. Many complex systems even have their own section of the application code dedicated to debugging- that is, a built-in debugger.
So? Gryzzex wants you to do it.

Unit-testing is important for complex systems. If you make changes to a core of an application which is providing an API for the rest of the application, you want to have a strong unit-testing system so that you know the changes you make to the API will not break the rest of the application... And changes to the API usually do break many parts of the system. With unit-testing in place, that's no big deal. You run the build procedure after making a change, see the error caused by the change, and go back. The build procedure should run 100's of unit-tests on a medium-to-large API. A developer of such a system would be quite naive not to have implemented some form of unit-testing for this situation. I mean, imagine making a change to one line, than making a test, refreshing.. making another test, refreshing.. etc, 100 times? A unit-test is the only way to go when you reach that point. The good thing about unit-tests, is once you reach the point of no return, you can still implement unit-tests.. You don't have to start coding from day-1 with unit tests in place.. It's not like, "Oh, I forgot to use [insert good practice here] on this project, so I have to redo the whole thing or just live with my mistake.."
The OP did not write the software and he won't program unit tests for it. This is basically the obligation of authors. For what you are teaching unit tests now?

Separation of responsibilities is important, too. You don't want to keep PHP code in the same file as HTML code, even though that's a feature of PHP which really helped the language gain popularity by dragging web-designers into the programming industry... It's still a bad idea. I would assume that a system becomes exponentially harder to debug as the complexity of that system increases. Mixing the client-side logic with the server-side logic doesn't help.
And again, he did not code it and he won't code anything himself. There are tons of idiots who fail this guide (including the author of cloudRealms, I guess), sadly.

For small applications, it seems silly to document every single step, create a build procedure, run 10's of unit tests, and the like. But you don't want to get caught napping when building complex beasts.. You want to take the time to make your code as easy to debug as possible from day-0, forward. Take the extra time to think about what you're getting yourself into before you start a big project.
The tread starter has nothing of PHP for himself. He is trying to use someone else software, that is just a mess.

Isn't everyone Ducking annoyed at how when you make a script then try to run it you get several errors? That happened to me when I was testing out this guy's script called . I hosted it through XAMPP and the index page had many errors. Then I hosted it through ###### (my favorite web hosting service) but still same errors.

So I edited the database files and the connections were working, but when I went into the config files, the text weren't separated from html to php. Can anyone try and run the game on their host to see if they have the same issue? I can't even log into the game!

(I am new - new but not new to forums)
Gryzzex, I won't be able to help you testing the mess for you, but let me clear out something: If you have to use software that is broken (so you have to fix it in the code), it has to be documented or you need much time. This piece of software is nothing good when it's huge and undocumented. Who knows what dependencies are inside of any line of code, what else will change when you change one line of code? In the best case, nothing than what you have changed. In good OOP this is true. But when I read that this guy even mixed html with php, you can be sure, there are many of evil traps that will occur. It's like fixing one bug, so it will open 3 other bugs, and it will open one hidden bug (thanks PHP, you are not even type safe, idiot!).

You should contact the author or have enough experience to not even fix this poop up, also repair it by rewriting the architecture. Then you are almost on the point where you can get your inspiration from this stupid dump poop code and it's ideas and build an entirely new software from scratch.

On your position I would rather try to find other software that fits your need.


(Also, for what advertising that hoster here, it does not matter where you host the files, plus, I know other hosters that are better at all.)
 
Last edited:
Status
Not open for further replies.
Back
Top