SVN bugs / Oddities Found, current build

[Peet]

This is what was changed.
It seems to be as it should be for Spin() so the problem must be elsewhere.

[Argh]

Ok... so, maybe put the default back in, but just define it as something absurdly high?

Meanwhile, lemme test setting an accelerate manually, and see what transpires.

[Argh]

Setting the value of acceleration does nothing.

Hrmm, this might be where it's happening...

Linky

[Argh]

Oh, check this out!

Two calls to variable value for speed here, on line 518:

linky

00518 AddAnim(ASpin, piece, axis, speed, speed, accel);

That's probably it. The other case reads:

00520 AddAnim(ASpin, piece, axis, 0, speed, accel);

[Peet]

No, that is all in order too. The first speed is starting speed, the second is final speed (after acceleration). If acceleration is 0, it automagically goes straight to the final speed, if acceleration is an actual number, it starts at a speed of 0 and accelerates to the final speed...

[Argh]

Then we're looking at a deeper problem- where it's drawing the speeds from the local-var...

[AF]

No NTAI build for SVN? Shame. Same for RAI... those guys need to open their source, it's the AI I've had to rely on for testing with random AIs, since KAIK and AAI fall flat on their faces...

NTai has been opensource for years. Its in the svn right now. But it isnt bundled with spring, and for very good reasons. If you had looked at NTai development in the last 9 months in any level of detail you'd know I've been crippled by graphics drivers and compiler issues and various mysterious bugs. The last verified as stable NTai was so long ago that its been lost forever, and bugs dont appear to be reported untill at least 3 new versions have been released making it near to impossible to debug anything that isnt in your face obvious or causes a direct crash in a debugger.

[Peet]

Or it's RAND. Try a few things like:

Code: Select all

var=number;
spin piece speed number;
var2=othernumber;
spin otherpiece speed othernumber;

If that works, it's RAND that's broken.

[Argh]

It's not RAND. Already tested that. And see my earlier note about how StartMoving() is no longer setting / transferring the state of a static-var correctly?

Something larger is borked here, having to do with how COB is accessing variables. Not good.

[Argh]

Well, here's something!

I set up a GET PRINT (RandomSeed2)... guess what value it's returning?

3

Which is completely, fricking impossible, if it's executing correctly. Lemme set up PRINT and check the other values...

[FLOZi]

I can see that they can interact with trees now(awesome!)

This was part of my fixes of the 'firestarter' tag. Who knows how long it had been in there not working

[Argh]

Every time I .give a Miner, PRINT returns the values of RandomSeed2, RandomSeed, and RandomTurn (in that order) as 3, 81, 0

Which is completely wrong, and shouldn't even be possible. Especially considering that the value of RandomTurn is being used properly.

It gets worse. If I put all three variables into GET PRINT parameters (was three separate lines), it now returns 3, 81, 81!

[Argh]

Ok, check this out. I manually set the value of RandomSeed 2 to 1000, and when GET PRINT tries to fetch it, it returns a value of 3. 3!!!

WTF! The thing that's really getting me, is that most of my Create() script is working, just not this stuff.

Ok... last test... I'm going to make all three variables static-vars, and see what values get returned...

[rattle]

Gnome noticed this one too. It has to do with PRINTing out local vars, static-vars are unaffected.

[Argh]

When all of the variables are static-vars, the values are properly randomized, and return normally. Oh, and everything works perfectly then, too.

So, either it's a problem with RAND, or a problem with local-var access to memory.

I'd have to vote against RAND, because otherwise the part that causes the TURN to happen, and causes random orientations Y of my Unit's Base... wouldn't happen. It does.

So... did somebody try tweaking access to local-var stuff? If so, why? Because it's pretty darn clear it's not working correctly, which is a pretty big deal.

Now I'm going to try making something to test and figure out why StartMoving is no longer properly changing the state of my on/off static-var that I use in my simpler, non-MotionControlled scripts...

[Argh]

The pathfinder seems to be rather borked, and is frequently locking up when Units exit Factories. I am getting constant errors, from factories and Units that operated flawlessly in 0.75b2...

[tombom]

What kind of errors?

[Argh]

"Path not found" errors, resulting in Units locking up and refusing to move out of the footprint of my Factories

I just got done playing for about an hour with PURE, using good ol' spawn-script (thank goodness it still works) and that was probably the single biggest issue I saw- perfectly good Factories getting stuck because of units refusing to move (apparently, the code that makes them choose the next waypoint if stuck isn't working now, grr), and I had to clear the clogs out manually, with very mixed results. I think that the pathfinder is having even more trouble with Footprints over 3 XY than it had in 0.75b2.

Also, the pathfinder's handling of Wrecks is abominable. I've seen multiple Units get hung up on Wrecks, where they could have solved their problems using simple right-hand-rule maze code...

[rattle]

Giving any order directly north of the unit doesn't work either yet.

[Argh]

Hmm... lemme try that one out, too... we're talking DIRECTLY north, or just north in general?