1.4 Status/Problem solving Thread.

#21 Hi, I also got a fresh checkout of the CVS of 1.4rc2, but when I compile it I always get the same error in Torque Tool lib.

fatal error C1083: Cannot open source file: '\Test\Source\torque\engine\console\basgram.cc': No such file or directory


I fixed the GuiVectorFieldCtrl::onAdd bug by adding "return true;" but it keeps happening.

Please help me!

#22 Ok, getting ready to update CVS tomorrow! So here are some replies...

@Matt Tuttle: Yup, committed your fix. Legacy of a shift in my string conventions. Good eye.

@Midhir: I've checked on the text edit controls and they seem to be solid at this point.

I've also rechecked alt-enters, everything seems fine in both debug and release build.

@Eric: Re: collision changes, I don't think we return normals that are signicantly different in that case. I think the values on the datablock are just turned up a bit, and the player is falling from a fairly high point... But the pointers to the PlayerData params are very handy, thanks!

@HyunGoo: I just checked, and BASgram.cc is definitely in CVS; I just pulled down a new fresh copy of it.

--------

I've also significantly revamped and improved the new font code, fixing lots of bugs, adding a bunch of console functions to manipulate the font cache, export and modify fonts in external programs, and other cool stuff. More on that in an upcoming .plan.

The core strings are also removed, since they were a) huge and b) out of date. Use langc to regenerate them if needed. Docs are on TDN (coming soon soon soon to SDK owners).

Fixed an issue in the scenegraph related to an optimization I put in earlier in 1.4 development. Now you won't get the "no zones found" error anymore.

And of course the fixes from this thread.

#23 I get the same error as greg Gardinier,


Fatal: (c:\torque\engine\scenegraph\scenegraph.cc @ 955) Error, no zones found? Should always find root at least.


....

#24 @Ben: I checked both the previous example and the new example player.cs datablock values in terms of "camera shaking". They're exactly the same! And in my game I had the player ALWAYS drop from a much much higher point than where it drops in you in the mission editor, and it never shook that much. I would look somewhere else than at the datablock values... something else has been changed.

I'll investigate it later - right now I have class ;).

- Eric

P.S. How or where exactly could I find out what code has changed since the last release?

#25 OK I am getting repeated crashes just trying to use a few of my GUIS that worked fine before the update. This one crashes and it hasn't had any scripting added yet so it should work no matter what.

I had the code posted earlier but a bit of experimenting answered my own question on why. It is the texteditctrl and if you where already using it, it will crash you game if you try it with the new engine.

#26 Another quick question...

Was this bug (timer drifting) fixed in 1.4 RC2?

- Eric

#27 Hoping these two were addressed? :-)

Topic: 1.4 Crash in resurrect() on driver change
Topic: 1.4 NetGraph crash with D3D, not OpenGL

The first sounds like it may have with the answer @Midhir.

And this is a general problem I see with the implementation unless I've (hopefully) misunderstood:

Topic: mFirstPerson / $firstPerson sync between client and server

#28 @James: Yes, it's fixed in SVN, and will be going out on CVS later today. Minor thinko in the SceneGraph code (it wasn't considering the root zone in all cases, even though it should.)

@Eric: A good diff tool, like Beyond Compare 2, would be invaluable - just compare suspect files using it to see what's different.

We have a new timer in TGE 1.4 that should be much more robust (ie, we rolled in the fixes that Clark did).

@Ron: GuiTextEditCtrl should work fine. It's used extensively in the existing GUIs and works flawlessly (or nearly so ;) there. Can you run in debug mode and see where it's crashing?

@Aaron: Why must you use D3D at all, especially on cards that support GL so well? ;)

If there's a broken case in the last issue, I'll look into it. (Ie, get a reproduceable bug.) For the other two, those are legitimate bugs and I'll check into them.

For everyone else: Please be aware that the 1.4 development cycle is coming to a close, and that pretty soon I will be unable to fix new bugs. Please get any issues in ASAP if you expect them to get fixed!

#29 I don't want to hijack this thread - but for those of you looking for specific changes that might have happened in the code I suggest you use this comparison tool.

ExamDiff

It does the well - and for free ;).

- Eric

#30 Well Ben I figured out what the problem was because what I did here makes it work. First, since there has already been so much mentioned here about the GuiTextEditCtrl that I immediately suspected the problem is there. So what I did was open one of my files with my old version that had GuiTextEditCtrl in it. I deleted all of the GuiTextEditCtrl on it and then it would open with the new engine. Then I opened a backup copy of the file, created a GuiTextEditCtrl with the new engine with the exact same entries as I put in before and compared the results. Here they are and I think you will be able to tell the difference.

The old version:

new GuiTextEditCtrl(accountName) {
         profile = "GuiTextEditProfile";
         horizSizing = "right";
         vertSizing = "bottom";
         position = "91 34";
         extent = "126 18";
         minExtent = "8 2";
         visible = "1";
         maxLength = "255";
         historySize = "0";
         password = "0";
         tabComplete = "0";
         sinkAllKeyEvents = "0";

and the new version....

new GuiTextEditCtrl(accountName) {
         Profile = "GuiTextEditProfile";
         HorizSizing = "right";
         VertSizing = "bottom";
         position = "91 34";
         Extent = "126 18";
         MinExtent = "8 2";
         Visible = "1";
         maxLength = "255";
         historySize = "0";
         password = "0";
         tabComplete = "0";
         sinkAllKeyEvents = "0";

Say what you will, but the capitalization changes make all of the difference here. I even went in with my old file and updated it to match and it works. I believe somewhere in the source there must have been a change here, I just haven't had the time to find it.

#31 I have had a brief chance to look through the GUI code and for right now there are far too many for me to list without thoroughly testing, but it seems that not all of the code has been changed to match the new capitalized sections and apparently the older GUI calls on part of that code that wasn't changed and therefore causes a crash.

Here is an example of what I am talking about:

void GuiBubbleTextCtrl::onMouseDown(const GuiEvent &event)
{
	if (mInAction)
	{
		popBubble();

		return;
	}

	mDlg = new GuiControl();
   AssertFatal(mDlg, "Failed to create the GuiControl for the BubbleTextCtrl");
   mDlg->setField("profile","GuiModelessDialogProfile");
   mDlg->setField("horizSizing", "width");
	mDlg->setField("vertSizing", "height");
	mDlg->setField("extent", "640 480");

   mPopup = new GuiControl();
   AssertFatal(mPopup, "Failed to create the GuiControl for the BubbleTextCtrl");
   mPopup->setField("profile","GuiBubblePopupProfile");

   mMLText = new GuiMLTextCtrl();
   AssertFatal(mMLText, "Failed to create the GuiMLTextCtrl for the BubbleTextCtrl");
	mMLText->setField("profile","GuiBubbleTextProfile");
	mMLText->setField("position", "2 2");
	mMLText->setField("extent", "296 51");

#32 OK this is frustrating. I can get some parts of my GUI created with the old system by going through and changing the capitalization in the GUI script but since I have no idea what all of the changes are it is a case of hit and miss between regular crashes that I can tell you are a real pain.

#33 Hey Ron,

Don't beat yourself up. I'll be fixing the case sensitivity in the next CVS commit - it is a bug.

Ben

#34 Thanks, good to hear.

#35 Hey Ron,

I can't seem to get that problem to reproduce, and a visual inspection of the code suggests that it's case insensitive. I'll note when I upload the latest SVN to CVS; when I do so can you please do a fresh checkout and make sure all is working properly? The key line is on line 609 of consoleObject.h, which reads:

const AbstractClassRep::Field *myField = getClassRep()->findField(StringTable->insert(fieldName));

The StringTable->insert should be making things case insensitive (ie, all strings with the same insensitive content should be pointing to the same value after being put in the ST).

Testing of script code seems to indicate all works as intended on this latest code, as well. My test function:

function doFoo()
{
   $foo = new GuiControl()
   {
      comManD = "hi";
   };
}

When I do a dump, command shows up properly capitalized (ie, Command) and with the right value in it ("hi").

Ok, back to work, want to get a few more things knocked down before I commit to CVS.

Ben

#36 @Ben: Just wanted to point you back over to this thread before the next migration in case you're keeping your eye on this one.

Topic: mFirstPerson / $firstPerson sync between client and server

#37 @Aaron: Reply posted.

#38 @Ben: Will do. Just give the word heheh.

#39 Ok, checked in the latest.

- Moved over to using xiph for all vorbis stuff and removed old vorbis lib dir.
- Enhanced GBitmap (some TSE upgrades/fixes/utility function type stuff ported back)
- Significant enhancements to font code (import/export/cache functions, caches properly, etc. etc.)
- Many small fixes.
- Mac platform updates.
- Fix for not-always-having root scene zone on global bounds objects.
- Compile fix for the GuiVectorCtrl.
- Ghosting consistency fix for triggers.
- console/ code cleanups.
- Fixes to stringbuffer class and GuiTextEditCtrl for non-functioning text field.

As usual, comments are welcome here. :)

#40 Quick update: I'm having some connectivity issues, so my commit may not have fully gone up. I'll check as best I can but if you do see oddities, let me know - it may just be that the commit didn't "take" properly, rather than a bug. This would especially be likely if the code didn't compile.