Need some help please

#21 @ jeff

So jeff where exactly can i find a list of these typos and thier corrections. so that i can know them when i see them in the book.

#22 Look through the topics on this forum. There are several that cover errors that I'm sure Ken will address in the next revision.

#23 Any idea when the revised copy's coming out?

#24 Okay i got a new problem.... i was trying to replace my code with the code from the cd to see which file of mine was bad, i ended up replacing everty thing so basically all of the book files are in the emaga folder. i didnt see the black screen anymore but now i conly see noise that is to say blurry graphics. I also ran the program from the cd and it works just fine.

#25 So you might want to check your hand-written files and the files from the book side by side - in cas you are interested in what was the problem.

#26 Ok well I too had the blinking cursor problem so i read this post and immediately began checking my files for errors/typos .. ok they're flawless, the reason that i know is because i have a program called CompareIt! which compares two files side by side... out of all of the files typed in chapter 4 there was only one difference between what it had and the book had, the book code for the player.cs file (in the book) said datablock PlayerData(HUMANMaleAvatar)
whereas the book code on the CD used PlayerData(MaleAvatar) .. now it runs fine from the Cd, so I made sure to change my own files to match the MaleAvatar dealy .. ok so now that all of my files were identical .. it still wouldn't run .. I thought maybe I had the path names wrong, or misspelled indeed I did NOT have them misspelled/misplaced.. then I went a step further, I went file for file and checked every one .. from the Cd compared to my directory structure for emaga .. an identical match .. so what's the problem ? i don't know, weird tge.exe files .. don't think so seeing as I copied the one directly from the Cd to my folder ..

I'm at a loss here... it works on the Cd, but doesn't work on mine, now i'm not stupid enough to trust my own error detection we're talking a computer comparison , says they're identical to the ones from the Cd yet it doesn't work .. ??

your guess is as good as mine, but man is that annoying?

#27 GRAAARRR

tried the next logical step which is to paste over the cd files with the ones in my directory .. it works now, but WTF lol ? the program wouldn't lie would it >.<

lol who knows.. i'm redoing this chapter..

#28 FWIW, I've been using Beyond Compare and it's been helping greatly with this sort of problem. Don't know how different it is from CompareIt!, but BC has become my standard diff utility these days.

HTH.

#29 THIS IS THE DEFINITIVE FOR THE FOLLOWING PROBLEM!!!!

"I used CompareIt! or another comparison program, and all of my files are identical to the ones from the CD .. but mine won't work .. but if I copy the files from the CD or run it from the CD it works.. WTF ? the comp says they're identical!"

OK .. I stopped reading this book for like .. 3 months because of this stupid problem .. I've re-read up until this point and I was determined not to let this sink me .. hopefully those with this problem will read it ..

I did a visual check of the files and I noticed a curly brace was a space or so off from the one from the Cd .. and I was like OMFG if this is a problem w/ white space I'm going to be really pissed .. so at first I deleted all the white space. Nothing changed .. ok the files still said identical to one another .. but I knew it had to be something with spacing .. (or so i thought) (lol .. as stupid as that sounds) .. OK well .. go under options (of compare it!) and you will see a little thing titled "Ignore NOTHING" .. or press CTRL+F11. Well I did that .. and guess what a ton of crap lights up .. this basically tells the program not to ignore spacing issues.. while most of these were formatting spaces, I went ahead and changed them one by one.. I mess with spacing for my own organization and here is where it came down to fixing the problem!

$pathList = $addonList !$= "" ? $addonList

etc..
I had this.. for my own organization:

$pathList = $addonList !$ = "" ? $addonList

can you see the difference ? one blasted space.. and that made everything else work ..

Solution: Set your comparison prog to not ignore spaces, check for non format related spaces that come up, and see if they would cause a conflict.. make sure to do this after a regular cleanup or else the whole document will show as being different!

#30 Call me stupid but i don't get it.

@ Alan so what you are saying is if you deviate with your spacing from what ken has in the book then the example programs won't work?

#31 @Marvin if you look at the two lines of code he posted, you have

$pathList = $addonList !$= "" ? $addonList

!$= is a string comparison $= negated. Eg blah does not equal blah. Where as the line he had in his code was

$pathList = $addonList !$ = "" ? $addonList

The space between the !$ and = made this into an assignment statement rather than a string comparison. As to whether it would compile and what error it would throw trying to assign to !$ I'm not sure. But the space between the two was the problem, not whitespace differences in general.

You'd be best only ignoring trailing or leading whitespace and blank lines in comparisons.

#32 I have run into this problem also, and I did atleast make it to the next step.

One thing before I get into this at all, someone had mentioned that the engine was terribly un-forgiving, and someone else said that any programming language would have problems with syntax errors like missing semi-colons. The problem here is that there is absolutely NO feedback on certain errors, just this hung console window. If I make a mistake like that, I would expect a compiler to give me an error I can fix. I have bought the Torque engine, I think its a great product, and I am excited about using it for my project. I bought the book and I want to work through it first before I get any deeper into code. The most troubling thing is this scripting stuff. The book tries to make it sound like a scripting language is a good thing rather than a leaky abstraction, but I don't buy it. Why not use CODE to add mods to this engine with REAL syntax, a real parser, compiler, editor, dubugger, etc. etc. rather than making up a new one? Just to keep people from having to get a compiler and learning a real programming language? Exercises like this show that your not doing newbies any favors re-inventing the wheel. I am REALLY REALLY hoping I can get away from the scripting language when I get into the full source, and that the engine does not depend too much (how much time have the developers of Torque wasted on this when they could have focused on other things?) on this scripting language nonsense.


Anyway, I worked through line be line in mine and simplified everything down, starting with main (a real debugger with break-points would have been REALLY nice here), and used the good ol' process of elimination to find where this hanging thing was. It turned out that it was in one of the Exec() lines in main. So I simplified that file down. The Exec() line BEFORE it worked. I found that I was never getting to the file itself, no matter how I simplified. It was really driving me crazy. I added a Test.cs in the same directory with the same simple code (just an Echo line), and it worked! Finally, I copied and pasted my original line back in place, and it WORKED!!!! When I copied and pasted, I was very careful not to add any whitespace on the ends, and that did it. It seems that perhaps there was some un-printable character at the end of my line. Perhaps some interpretation of /r/n or whatever. I know that some text editors do different things with endline characters? I may have typed part of this in word pad and other parts in VisStudio and now I am playing with UltraEdit32. I didn't think to look deeper at the hex, although I should have, sorry. I was just happy to move on.

So it FINALLY ran, then I see the stuff other people are seeing. It seems as though I ran the wrong installer from the book or something? I will look into that next. I am seeing the regular Torque intro screen (not the books), but it is all garbled looking. Looks as if there is a drawing problem based on not properly evaluating the resolution of the image. I saw that the resolution was set (by default) to 800x600, and that when I run the other examples it was 1024x768. So I set the resolution in main, and the image showed properly YEAH! (although I don't think that was what was intended for Emaga4).

I am now having the problem with the trailing mouse cursor (like a paint program, leaves a red trrail on the bitmap, cannot press any buttons). I think I saw another thread on this, so I will research it. Its frustrating that none of this stuff was in the book. Its trying to teach the basics of syntax, but to make the examples run, you have to REALLY REALLY watch your step.

Is there a centralized place where these kinds of problems can be found. I think that most people, especially the newbies this book is made for, are not going to be willing to run through all of this rat race to find the answers. Don't get me wrong, I love the book Mr. Finney, and the engine, and the community.

Thank You
-- Rick

#33 I haven't tried it yet, but there is a "trace" ability built into the engine:

trace(1); //enable tracing
  trace(0); //disable tracing

From what I hear, this dumps every line of script being executed to the console (and its .log).

#34

Quote:Why not use CODE to add mods to this engine with REAL syntax, a real parser, compiler, editor, dubugger, etc. etc. rather than making up a new one? Just to keep people from having to get a compiler and learning a real programming language? Exercises like this show that your not doing newbies any favors re-inventing the wheel. I am REALLY REALLY hoping I can get away from the scripting language when I get into the full source, and that the engine does not depend too much (how much time have the developers of Torque wasted on this when they could have focused on other things?) on this scripting language nonsense.

Scripting languages have and are being used for many things. In this case its a way to modify the game without actually compiling the engine. Unreal (2004) and HalfLife (2) are other games that have scripting. Obviously if so many games use it it can't be as bad as you seem to think, at least that would be logical deduction. It increases the usability of a game exponentionally, giving the user options to add parts of the game considering games don't ship with their source.

"scripting language nonsense"... that nonsense is what made Tribes and Tribes 2, its why Unreal Tournament is as popular as it is today (among its engine) and why Half Life 2 (as well as other games with scripting languages) have such a continuing fanbase. I suggest you do some research in the counter-argument of your argument before you evangalize against it.

Besides some of the most popular games and the most powerful engines using a scripting language is the fact that it makes updating games much easier, its 10 x quicker to just change a few values in a script file and run the game vs. changing c++ and recompiling.



and trace(1) works great... another usefull command is tree()

also just a note for those that don't know (I'm sure most of you programmers do)... trace(1) is the same as trace(true)

#35 I must admit, that a big part of my previous rant was closely related to the frustration of working through some of the issues mentioned. I am not the first to see this stuff, and I am very thankful for a great user community here. On a side note, I copied over the CH4 resources and then just copied my files in and everything worked fine. It seems that maybe the Emaga4 installer is missing something. I moved on to the coolness of the next chapter.

From what I have read, main.cs runs a little differently. I wasn't seeing any console output from Echo() until I overcame whatever was hanging do to the strange non-printable character or whatever. Would the TRACE() work?

Yep, lots of games use scripts. I would not mind using a script for a small modification, but this is writing the entire game in the script. I can see why people wouldn't want to reveal source code, but they could provide public interfaces to DLL's just as well? You wouldn't have to re-compile everything, just your MOD .dll. Ah, I suppose that might break some cross-platform capability.

I suppose everyone has their opinions about this, and I may be in the minority. I will take having to re-compile ANY day, just give me type safety, and most importantly, a nice debugger. And no, I don't think TRACE(), ECHO(), TREE()? are as nice as being able to set a break-point.

Once again, didn't mean to slam anyone. I love the engine, the book, and the community. The experience has taught me more about the engine than I would have otherwise learned. Perhaps I am just a C++ snob.

Regards,

#36 Just keep in mind that the exercises in the book are designed specifically to only require scripting. As TGE licensee, you would have full flexibility to port each and every possible thing over to C++ if you like, or do all of your new implementation in C++ for derived classes, and simply provide the script "hooks" (ConsoleMethods, and callbacks via Con::executef(..script info here..) ), which is actually how Torque is set up.