1.4 Status/Problem solving Thread.

#1 Hey Ben,

When I create/select a water block I am getting this error in scenegraph.cc

"Error, no zones found? Should always find root at least."

I also get this exact same error if I try to scale the terrain.

#2 A quick question - has the new enchanced TelnetDebugger code been applied to 1.4 RC2? When I tried a copy/paste - upon recompiling I get about 620 errors... ;).

Unless I'm doing something horribly, horribly wrong (just copy and paste right? :P).

- Eric

#3 I saw in Ben's .plan that 1.4 has both an integrated file browser and color picker. Is this supposed to be in RC2 or the final 1.4 release? These 2 features aren't popping up in the build I just did. Other than that, digging the new features. Great work guys!

#4 I have a couple of minor gui problems. In the mission editor when I click the text cursor on the last letter of a text field, I can only select up to the left side of the last character. I have to use the arrow key to get the cursor to the right side of the last letter.

Also, when I click in the middle of a text field that contains text, if I backspace letters, the letters to the right of the cursor become different letters/numbers/symbols than they were before I hit backspace. This makes entering colour values very difficult. Are these engine or script bugs? Where should I go about looking to address these issues?

#5 This is what I am getting when trying to compile Torque Tool lib.

c:\cvsmodules\torque\torque\engine\gui\utility\guitransitionctrl.cc(67) : error C4716: 'GuiVectorFieldCtrl::onAdd' : must return a value

and

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

#6 I managed to fix the GuiVectorFieldCtrl::onAdd bug by adding "return true;" at the end of the function. That seems to be the way things should be done, looking at other ::onAdd methods. It compiles, at least.

#7 I'm not sure if this is the spot to put issues, but here are some. I'm not sure if I have the latest version or not but I pulled everything from CVS head.

-Mission editor drop to ground seems to not work for me when using Atlas terrain.
Crashes on ln 53 becuase SimObject *obj = NULL.

-Call to generateTQT crashes if source jpg file not found.

I've come across more and didn't write them down. Should I be posting them here as I find them. Maybe I should batch them and submit a txt file or something?

Eric P

#8 @Kevin Mabie,

Eh? That's not TGE, is it? Looks more like TSE.

#9 Opps sorry. Is there a TSE place for these? Being somewhat new I thought that TSE was in version 1.4. But seeing that it hasn't been released yet it shouldn't have a 1.x release number. My bad.

#10 Try the TSE forums :) There's no specific thread, but just pick whatever forums fits it.. maybe the Bugs section?

#11 I've run into something that hasn't been mentioned so far.

I'm using MS Visual Studio .NET 2002 (7.0.9466).

When the system goes to compile missionMarker.cc I get these errors:

'registerType' : is not a member of 'Con'
'registerType' : undeclared identifier


The call is in void WayPoint::initPersistFields()

Con::registerType("WaypointTeam", TypeWayPointTeam, sizeof(WayPointTeam), getDataTypeWayPointTeam, setDataTypeWayPointTeam);

When I comment that out I also have to comment out the

addField("team", TypeWayPointTeam, Offset(mTeam, WayPoint));

line because the link fails with

unresolved external symbol "int TypeWayPointTeam" (?TypeWayPointTeam@@3HA)

I went digging and the only declaration for registerType I could find was commented out in console.h..
I've gone back to CVS to try and verify everything came over properly, even pulled a completely clean copy in a new directory.
Not sure why no one else is running into the problem.

Also the VC7 (7.1? or are they 8.0?) project files use alot of .\../engine and similar references. I always have to go clean those up to just ../ to get things to work properly for me.

-Jerry

#12 Hey guys,

Monolithic reply here. Got called away to do some other dev tasks for some projects on very short deadlines. So... on with the omnibus! :)

@Greg: Interesting. I will look into that ASAP and give the editor a good click-through.

@Eric: Much to Spilman's dismay, the 1.4 console code has been cleaned up a fair amount. So the patch won't work out of box, though it should be easy and clean to update. (Sorry Tom!)

@Kevin McMurphy: Hmm, should be in. I'll double check.

@Midhir: Sounds like you don't have a full/clean update. Those are both bugs that happen from GuiTextEditCtrl or stringBuffer.cc being fully up to date.

@J: Hmm, inexplicable since I'm pretty sure I compile those files! But I'll definitely look into that.

@Kevin Mabie: Yup, TSE is the place to go!

@Jerry: We changed the way console types are registered to be easier, cleaner, and actually documented! That looks like an oldstyle definition. If you look at consoleTypes.cc you'll see some example implementations you should be able to ape. Once TDN goes up for SDK owners you'll also be able to review some docs that explain how the stuff works now. I'll also be setting up an 1.4 upgrade guide page on TDN.

#13 @Midhir - I had this same problem. If you take a look at line #230 in guiTextEditCtrl.cc you will see the following code:

for(count=0; count-1; count++)

If I am not mistaken, you can remove the "-1" and it will fix your problem.


One of the problems I have, is in the world editor. If the player falls from a certain height, the camera bounces around for a while before leveling out.

#14 @Matt: Believe it or not it always did that. Or at least it was always supposed to. In my game, the player can jump extremely high. I noticed when he landed the camera shook. I thought it was od, so I took a look at the code. Sure enough - the code was actually in there. No bugs. However, I believe that the camera was (in 1.3 / 1.4 RC1) supposed to shake at a much lower threshold when I remember looking at the code. I didn't bother investigating it at the time. In 1.4 RC2 I noticed the dramatic camera shaking as well - but then I thought to myself "they probably fixed that bug", so the threshold that the camera was supposed to shake at, now is. And it's a little too much, I agree ;).

If I get around to coding today - I'll see if I can post a quick fix.

- Eric

#15 Eric's right - camera shake is a feature, not a bug. :) Though I agree it's a bit overstated; it'd be great if Eric can give me a tweak for it!

#16 Also, thank you Matt for the fix, will definitely check that in ASAP.

#17 Alright, here's what I've been able to gather from the code and the over-the-top camera shaking.

As far as I can tell, nothing has changed in the base player code. This includes all values for amplitude, frequency, fall off, minimum speed, anything and everything relating to the camera shake.

However - the one piece of code that grabbed my attention was.

F32 bd = -mDot(mVelocity,collision->normal);

         // shake camera on ground impact
         if( bd > mDataBlock->groundImpactMinSpeed && isControlObject() )
         ...

I'm pretty sure the guys at GG have modified the collision code. So I'm thinking a modification in the collision code, something as simple as a collision normal probably has changed since the last release.

Which leads me to believe that the collision normal is dramatically different than it is now, and one of two things.
a) It's now fixed.
b) It's now broken (or it hasn't been normalized?)

I believe that collision is Matt Fairfax's area of expertise (and this is really is a shot in the dark - I'm sure Ben is just as well versed in the collision code :) ). So that's as far as I can investiagate for now without spending oodles of time trying to figure it out completely.
I've got problem sets to catch up on tonight...

So a quick fix for those of you who really need it - simply jack up (or down) the values of the following fields in your script (in your player definition datablock)
groundImpactMinSpeed
groundImpactShakeFreq
groundImpactShakeAmp
groundImpactShakeDuration
groundImpactShakeFalloff

They're pretty self-explanitory.

- Eric

#18 I found two more simple changes for the TreeView control in the GUI Editor. The first is to correct the highlighting problems and the second fixes the dragging problems. The TreeView is great by the way!

example\creator\ui\GuiEditorGui.gui:
Change:

function GuiEditor::onClearSelected(%this)
{ 
   GuiEditorTreeView.clearSelection();
}

To:

function GuiEditor::onClearSelected(%this)
{ 
   GuiEditor.clearSelection();
}

engine\gui\controls\guiTreeViewCtrl.cc and guiTreeViewCtrl.h:
Change:

void onmMouseDragged(const GuiEvent &event);

To:

void onMouseDragged(const GuiEvent &event);

#19 Ben wrote:

Quote:
@Midhir: Sounds like you don't have a full/clean update. Those are both bugs that happen from GuiTextEditCtrl or stringBuffer.cc being fully up to date.

I assume you meant _not_ fully up to date, but I just got a fresh checkout of the CVS of 1.4rc2 and compiled it. The problem still persists, is there something I'm missing?

[edit]
Sorry I just read Matt's response and removing the -1 fixed the problem with placing the cursor to the right of the last character in a text field with the mouse.

I also implemented his fixes for the dragging and found what looked like it should be changed:

function GuiEditorTreeView::onDeleteSelection(%this)
{ 
   GuiEditor.clearSelection();
}

Should GuiEditor. be changed to GuiEditorTreeView. ?? It seems to work for me when I change it.

#20 Forgot to mention in the last post that there is a crash with
starter.fps when switching from windowed mode to full screen
mode, and when changing most graphics options from in-game.


*** Phase 3: Mission Lighting
Successfully loaded mission lighting file: 'starter.fps/data/missions/stronghold_f4d4221.ml'
Mission lighting done
Mapping string: MissionStartPhase3Ack to index: 2
Mapping string: MissionStart to index: 11
Mapping string: SyncClock to index: 12
Could not locate texture: starter.fps/data/shapes/player/crossbow
Could not locate texture: starter.fps/data/shapes/player/clip
*** Initial Control Object
Activating DirectInput...
keyboard0 input device acquired.
Could not locate texture: starter.fps/data/shapes/player/crossbow
Could not locate texture: starter.fps/data/shapes/player/clip
Mapping string: Kork to index: 13
keyboard0 input device unacquired.
==>echo("The game is running fine, this is being typed in the console.");
The game is running fine, this is being typed in the console.
keyboard0 input device acquired.
Setting screen mode to 800x600x32 (fs)...
Killing the texture manager...
Making the rendering context not current...
Deleting the rendering context...
Releasing the device context...
Destroying the window...
keyboard0 input device unacquired.
DirectInput deactivated.
Changing the display settings to 800x600x32...
Creating a new full-screen window...
Acquiring a new device context...
Pixel format set:
32 color bits, 24 depth bits, 8 stencil bits
Creating a new rendering context...
Making the new rendering context current...

I hit alt+enter just after the echo line and the game crashes every time
I'm at a loss to explain it, but I figured somebody else would certainly have
more insight into the problem.