Oh Bad.. All kinds of issues cropping up!

[Periculi]

I can't figure this one out at all.


For some reason the game is really messing things up!

I should probably send you the entire file set for system26, George, so you can see if you can find where I broke it.

Here is what is happening-

I start a game in a system that has only a Station which serves to prepare some data for a game.

When I am done selecting a map, I get transported to the "start system" - in all my sample maps this has been Eridani.

Ok, everything seemed to be working fine- the game loads, the extra gates are destroyed, and a system is delivered that matches what I requested for the gates.

Then it got weird!

I used a system map to locate all the stations, etc.

I went through a stargate to the next system.

I went back through the same stargate, and Eridani got re-built- like I had just arrived there- no map locations known, everything had moved, it was like it wasn't getting stored!

Then I went through the gate again, and Groombridge was fine!

Then I went through the gate again and got a NEW Eridani!

Some other really odds things are going on, but what could be the cause of the game losing the info on Eridani?

Another problem is that if I start the game and exit, or play a little and exit, the save game won't work.

So what could be happening to it?


Ok, I tracked the problem down- it's the gate removal.

This is a major problem for me.

What is going on with the Stargates that makes them so important to the savegame and the system build? Why would removing a stargate from a system cause the system to not be saved properly in the save game and why would it cause so many other little bugs?

Seems like the stargates are doing more than just being spaceObjects, and they are attached to some very sensitive information for the game!

Regardless, whatever the stargates are doing has pretty much completely blocked me from having an map mod that functions enough to play.

Any thoughts George?

[Betelgeuse]

hmm random idea (don't know if it will work)
instead of destroying gates just have them start very far from the system and just move them in and out as needed. As long as you put them out far enough the chances of finding one at random are nearly zero. (I am not sure if you can fix the showing up on the map issue but if they are far enough away that will not be a problem)

[Periculi]

It's funny how often we end up with the same ideas.
I think that might be one solution, and I could put a <OnObjRecon that made the moved gates move to the other side of the system if the player got too close.. lol


However- this error never happens in my prototype!

I am unsure what is going on, but it seemed to be the (objDestroy on the gates because when I started tracing the problems I found that if I comment it out that single line fixes the problems...

I am curious about why.

The gateSwitch works great in the prototype using basically the exact same code, so if it works there why is it causing problems for the mod now?

It is really confusing to say the least.

[Periculi]

Well, Betel the moveTo fixes what was going wrong.

But I am still at a major loss to understand why something that was working perfectly well in a prototype format doesn't work at all on a larger scale.

I cut out everything except the gateSwitch code for my mod, then I tested it to reproduce the errors with no chances of the code being messed up from somewhere in the other functions I wrote.

So- I have a version of the prototype gateSwitch scaled up to the System26 topology of 531 nodes each with 26 gates, without any mapper or other functions in the way = nice and clean.

For some reason, it doesn't work like the original prototype set up on a 10 system topology with 12 gates per systems.

The ONLY difference is the number of gates and the number of systems.

So, what that seems to be saying is that the number of the systems and the number of the gates is effecting the game systems and causing bugs and lost data when the gates are destroyed or gated out to a different system.

Am I running into some kind of overflow due to the topology size? I have used huge topos for months without any problems!

And why would destroying gates cause the Save game to corrupt? And the systems to not remain in memory?

Another question is why would removing rootNode="true" from Eridani cause the map node scanner to be unable to find all the active nodes?

What happens when the game starts is the massiveDataArray is initialized, and a quick check is done to make sure that the array is representing only nodes that exist in the game- to do this I use (if (sysSetData ) to test if a variable was set or not on the systems. When the gateSwitch used (objDestroy, and the save game bugs were happening, I changes eridani to not have the rootNode to see if it would do anything- what it did was make every node check on the (if (sysSetData come back invalid for nodes that I know for a fact are there- all of them, every node in the list was unable to be detected!

Why would (objDestroy on a stargate spaceObject and removing rootNode="true" from Eridani's topo tag cause the entire topology structure to become invalid? Put the rootNode back in, and the node check works fine.

Now that I am not using (objDestroy, but moving with objMoveTo on them instead- Eridani doesn't care whether it is a rootNode or not. Every node validation check functions perfectly.

Go figure.

George- I have a variety pack of files that represent the various stages of this experiment and bug issue if you want them.

[george moromisato]

George- I have a variety pack of files that represent the various stages of this experiment and bug issue if you want them.

Yes, please send them. If there is a particular bug that you want me to address, please package them up so that it is really really easy for me to reproduce the problem.

[Periculi]

Ok, I sent you a PM with the link to get the mod sample files.


Edit- I figured out that the Nodes being shown as unvalid was due to not having a stargate listed for the entry system. Now it has one even though it doesn't show up, so the topology gets validated by the node checker for the maps. It was a little odd that the node validation wasn't working but the topology would play still. Somehow that threw off the result of (if (sysSetData checking for existence but didn't prevent the game from playing.

Still don't understand what is wrong with the gate switch (objDestroy method.

[Periculi]

Hmm, some other interesting bits from my attempts to understand this strange behavior:

A system type tag without a star or other features, except a station and a gate can be placed in a module but cannot be placed in transcendence.xml

I tried putting all my star system definitions back into trans xml, and the game wouldn't start- unable to build the system. It was fixed when I altered the starting system definition to conform by using Elysium's definition. Curiously, this neither helped the bug nor made any observable difference. It just seems odd that the star system definition would work in a module but not as part of Transcendence.xml.

I tried reducing the number of systems in the topology to 92-93, from 531. No changes in the bug with objDestroy or objGateTo removing gates.

I tried reducing the number of gates in the systems from 26 to 8. No change in the bug.

Now I am totally mystified- I have one prototype that works perfectly, but only uses a 15 node system to test its functions on- it can destroy a gate and no problems occur.

I have four or five varying sized topologies using exactly the same code, and a few improved variants (that all work in the prototype!) that reset the systems- intermittently. On some games, the first system remains in the game- in others if you leave it and come back it's reset to a new system.

Sometime other systems also get reset.

No system has yet been reset in the miniature topology prototype.

So, what kind of error is this? Is this another one of those hidden limits? Is 35 nodes the max for a stable transcendence game? Why does objDestroy work fine for one version of a topo and not another?

I have picked through the prototype a few dozen times to try and see what is being done differently- and I swear to you the answer is nothing.

At any rate, objMoveTo is really not going to work. I need to destroy the gates or gate them out of the system. I know that this is possible. It works. But something is unstable in there.

Tell me why a star system definition would work in a module but not in trans xml, for one thing.

[Periculi]

I tried to reproduce the bug on a fresh file set by just setting an inbound gate in Eridani and an on create event to destroy it. This works fine.

So, I know objDestroy works without issues.. on that scale.

[Betelgeuse]

noRandomEncounters="true" allows you to turn off random spawns you would also need to rework reinforcements but all of that would need its own mod

are your nodes root nodes? I think that might effect it. (try making them all root nodes)

[Periculi]

Well, the nodes that I am checking- namely the first one- is a rootNode.

What I don't get is why I can't reproduce the bug easily.

[Betelgeuse]

but going to a node with no way to the root node might make that the new root node and everything it can't get to is cleared from memory (just guessing)

[Periculi]

Then how is that avoided in the case of Elysium? And why would it only be an issue when a gate is destroyed?

Addit- Still More Fun With Strange Bugs!

So, I tinkered around and found a strange bit more going on.

The first system is a rootNode, and so is the second system.

The first system removes no gates, but only has one active gate- an exit to eridani.

The second system has 26 gates and all but 2 get removed. - this causes the system to reset.

The first system remains stable.

Adjusted the second system to only up to 12 gates and then the second system is stable. Went to the third system, with 26 gates, and it was, of course, unstable.

Adjusted the third system to only 12 gates. Went back, first system was stable, second was stable, third was still unstable!

So, 12 is not the magic number for the third system... but it is for the second?

But, this actually only works occasionally. I reduced the systems down to 8 gates, and still got reset systems happening. rootNode for all of them didn't help any, rootNode for only the beginning system didn't change anything.

It just doesn't seem that a stable game is happening, and so even if I use objMoveTo which doesn't cause the gate bug, who is to say it doesn't cause a great deal of other bugs.

The worse part is that this is only occuring in larger topologies. I am unsure of what the minimum is to have a stable result, but the tester I am using has 5 nodes and no matter how many gates I place to be destroyed the system never resets and so I am unable to reproduce the bug on a small scale test.

However, I know that the minimum isn't over 90.

[Betelgeuse]

idea (more to see what is going on)

have a system with lots of gates (where a system on the network is unstable)
every other system has some data you can get to with sysGetData
remove one gate and check the data (it shouldn't change)
do that for most of the gates

when there are few left (like 2 gates left) gate out and sysGetData on the system you just left to see if it is gone

gate back to that system if the sysGetData passed

where in this is the error occurring?

[Betelgeuse]

new idea dummy system that the player can't get to that links to every system (it would be a root system of course and those gates never get removed)

[Periculi]

I already have one of those, Betel.

I am going to give this one up for a while. It seems to me that the number of gates and the number of systems in the topo make the game act unstable. Unless George fixes that, it won't work. I am apparently trying to get a simple line to stretch in more dimensions than the designer intended.

The thing I feel is that it would be easier to redesign the spawns and missions than it would be to find out the bad news about why objDestroy is causing so much instability.

Actually, I feel it would be easier to fix this from the source, so that more of the possible reasons for it's cause could be seen. This is a problem that isn't really caused by the scripting, it's the game engine acting up under the strain of so many items to keep track of.

So I am going to keep using objMoveTo [very far away] to 'destroy' the gates and hope that the game will play stable enough to make this mod worth something.

I seem to recall digdug also mentioning some other odd and sundry wierd behaviors when play testing for me.