Author Topic: Testers Needed! (Read 10459 times)

Sirbomber · « **on:** October 23, 2008, 08:28:18 AM »

I have some good news and bad news, folks.
The good news is that I think almost all MT2 techtree and sheets related bugs are gone.
The bad news is that one bug that I thought I fixed long ago still remains.
Apparently there is a bug that adds a small rare ore cost to Robo-Miners. This means that people cannot get rare ore. Obviously, this is a serious problem.

So I need some people to very carefully test this bug. Players will research one tech at a time. When someone finishes researching a tech, that player will tell everyone else, and all players will check the Vehicle Factories to see if Robo-Miners require rare ore to build.

Please, people! This is the last known major bug!

Hidiot · « **Reply #1 on:** October 23, 2008, 09:22:50 AM »

I have yet to see this in the colony game.

Sirbomber, what is the minimum number of players on a map to make the bug appear?

If I can hold my composure until later tonight, I'll try the multi player map (against myself) and see what happens.

Sirbomber · « **Reply #2 on:** October 23, 2008, 11:34:19 AM »

Hidiot, none of these weird bugs show up in single player games.
You'll need at least two players, most likely: one who researches and one who checks the effect on their Robo-Miner (and other vehicles/structures?).

Edit: Having said that, there are some colony-specific techs...

Hidiot · « **Reply #3 on:** October 23, 2008, 02:06:46 PM »

Ok, tested, seen it, forgot to note where it was exactly

(Better luck next time)

Sirbomber · « **Reply #4 on:** October 25, 2008, 03:50:29 PM »

You have failed. Our colony is surviving nevertheless.

Sonnebahn · « **Reply #5 on:** October 30, 2008, 05:58:58 PM »

ok, since no-one else has posted the resolution of this matter here are the results of my testing:

following a straight line to rare ore refinement I encountered 62 rare ore required on the robo-miner of the Host account in a two player game with both playing plymouth. The tech path I followed was identical with both games as follows:

Computer Sciences
Robotics
Chemistry
Astronomy
Planetary Sciences
Physics
Earth Military Database
Advanced sensors
terrain manipulation
Hostile environmental mining
terrestrial geology
Rare ore refinement

The trigger was the Join account finishing the rare ore refinement. Is there by chance an event associated with this technology in a multiplayer game that is in the hard coding? or perhaps something associated with that particular tech number? Or is it the addition of common ore to the miner's cost that messes with the coding? Since there is no 62 value listed in the tech-tree I do not think it is in the tech tree but how the code deals with that particular tech number. But these are just my random thoughts on it, you all are much more aware of the intricacies of the code.

Sirbomber · « **Reply #6 on:** October 30, 2008, 08:35:54 PM »

Baah, I'll need to test this myself I guess. Too many conflicting reports.
Besides, the way these bugs work, the host shouldn't be affected.

Thanks for your help, though.

Freeza-CII · « **Reply #7 on:** October 31, 2008, 11:14:54 AM »

I had seen a simular problem like this before playing as eden on flood plains stock game and some how a unit got a odd ammount or rare ore needed to make the unit and it wasnt one on the normal units that get rare ore.

Hooman · « **Reply #8 on:** October 31, 2008, 04:42:17 PM »

Actually, I was thinking the host is probably more likely to be affected by this. They'll be Player[0], which seems like they'd be the default for any ill effects.

If this could be reproduced in single player, maybe with a test level that has a bunch of things already researched, then this may be easier to track down. I took a look at some of those mentioned techs, but didn't see anything in the tech files. This could potentially be a bug in the game. At any rate, it should be fairly simple to place a hardware breakpoint on the rare ore required for a robo miner, and research a bunch of things until it fires. Then we'd know at what point in the code this happens.

Hooman · « **Reply #9 on:** November 15, 2008, 04:44:24 AM »

Ok, I have good news and bad news.

The good news is that I found the bug. The bad news being what you'll have to do to fix it. (Or rather what you can't do).

You're getting the rare ore required set to 62, because that last tech researched (Rare Ore Refinement) just happens to be tech number 62, after they are sorted by ID. The reason why this happens, is because when a tech upgrades a unit, it records the number of the tech in a static array. This is how you get those upgrade strings in the command pane when you click on a unit. It uses those tech numbers to lookup the tech, and shows it's corresponding upgrade string. The problem is, that static array only has room for 2 entries. After that, it starts into the unit data for the next player. Hence why when player 0 researches this tech, player 1 would have the rare ore cost set. (Well, the rare ore just happened to be the first entry in the next player's data that was set to 0, and was thought to be an empty array entry).

So basically, you can't have more than 2 seperate techs upgrade the same unit. You are however allowed to upgrade the same unit multiple times with the same tech, (I think).

In other words, rewrite your tech file. =(

I suppose you could upgrade units using a research trigger callback and some mem hacking if you needed to exceed this limit, but that's not self contained in the tech file, and anyone designing a level for that tech tree would need to use that custom DLL code.

I suppose I could look into writing a patch to prevent it from overstepping the array bounds. I make not promises though. Plus, there might be other problems that crop up. There's also the minor nuisance of only the first two upgrades getting a string listed. That's not easily fixable though due to the static memory allocation. Which again, leads back to rewriting the tech file to avoid odd behavior.

Hidiot · « **Reply #10 on:** November 15, 2008, 07:05:38 AM »

Another solution is re-designing the game the way it should've been designed in the first place. but that's... not a good solution for now.

Sirbomber · « **Reply #11 on:** November 15, 2008, 09:16:53 AM »

That's not bad news! It means I have an excuse for not writing IMPROVE_DESCs!
Suck it, Hidiot! Mwahahahahahaaaa!!!! :evil laugh:

The reason I have so many techs improving the miner was so I could have IMPROVE_DESCs for all the things I upgraded on the Miner, you see.

Edit: Fixed in less than a minute!
Maybe.

Sirbomber · « **Reply #12 on:** November 18, 2008, 08:12:40 PM »

Hmmm... This probably means I can't upgrade the Agridome 5 times...
This might complicate my "upgrade things a lot as the game progresses" idea. What exactly are the limitations? I can only have two techs upgrade any single building, or I can only upgrade the same thing twice, or...? I'm a little confused, Hooman.

Hooman · « **Reply #13 on:** November 19, 2008, 06:11:01 AM »

You can only have two techs upgrade the same unit. The same tech can upgrade many properties of the unit though.

Sirbomber · « **Reply #14 on:** November 19, 2008, 06:45:46 AM »

Mmm... This complicates matters...

Hidiot · « **Reply #15 on:** November 19, 2008, 07:36:51 AM »

Since they're static limits, I assume they're set to whatever the original developers used.

Units should have 4 upgrade strings and possibly a few more upgrade room too, whilst buildings have around 2 (though GP's also have more strings). Because the original game only had up to two upgrades on buildings (GORF and Smelters for example of only two upgrades)

Sirbomber · « **Reply #16 on:** November 19, 2008, 09:23:08 AM »

No, Hidiot, but I see where you are confused. Two for the GP/chassis and two for the weapon = four.

Hooman · « **Reply #17 on:** November 19, 2008, 12:30:17 PM »

That probably what it is, since the indexing is the same for all unit types in the upgrade code. That would imply the same static limits for both buildings and vehicles.

Sirbomber · « **Reply #18 on:** November 19, 2008, 05:54:58 PM »

So, Hooman, do you think a fix for this is likely, or should I plan on making some major changes?

Hooman · « **Reply #19 on:** November 19, 2008, 06:01:19 PM »

You're probably better off changing things. I don't have much time for patching right now, and there are certain things that can't really be patched easily. Like say, increasing the number of available slots in that array. At best, I could probably patch it so it doesn't overwrite the wrong thing when there are too many techs, which still leaves the upgrade strings missing after the first two upgrades.

Sonnebahn · « **Reply #20 on:** November 20, 2008, 12:48:47 AM »

One possible fix would be to have it override the 2nd entry with any subsequent upgrade. Then if the techtree was made specifically sequential you just make upgrade text entries that are summaries of what has gone before plus the new upgrade.

Sirbomber · « **Reply #21 on:** November 20, 2008, 06:15:52 AM »

Quote

At best, I could probably patch it so it doesn't overwrite the wrong thing when there are too many techs, which still leaves the upgrade strings missing after the first two upgrades.

Actually, that'd be perfect for my purposes. But if you don't think it will be easy, I'll just have to try to find a way around it.

Of course, I have no idea how I'll do that... This really screws up the whole idea behind MT2...

Hooman · « **Reply #22 on:** November 20, 2008, 07:07:36 AM »

I don't really see this happening. At least not anytime soon. If anything, I'd be easier to patch it so new techs don't add or change the existing strings.

Sirbomber · « **Reply #23 on:** November 20, 2008, 07:59:38 AM »

Well, at least we finally know what was causing the problem!

News:

Author Topic: Testers Needed! (Read 10459 times)