Such a developer...

There's people who just hop in and fly the plane and the ones on the ground yelling at them, "Hey--you can't do It like that!".

I don't use a script either.  When some joker has a bunch of files in the directory that aren't in use it surprises you with all kinds of problems.

I'm an oddball and use both a script and manually entering names. Then you get the fun part of removing things from your entity.manifest (assets that seemingly aren't in use) and hope it doesn't crash the game.

Well, I'm the only joker on my mod so...

And I use exclusions via ant for the dead Ironclad stuff that shouldn't be included.

You have a whole mess of bad terminations in AbilityIsDunov.

OnCondition's with OnDelay finish, OnDelay's with OnCondition finish.  Almost that entire asteroid buff chain has them backwards.  The OnDelays will still fire with an OnCondition finish, but the reverse is not always true.

You should also change BuffIsDunovCargoSpeed to finish on LastSpawnerNoLongerHasBuff, and switch it to PrioritizeOldBuffs, would be a major performance gain for that ability.  You can have 50 plus trade ships in a well pretty easy, having it reapply needlessly is a noticeable waste of cpu time.

The principle behind your design is sound, it might even be finished once you correct the termination flaws.  I didn't keep looking for errors once I spotted the obvious ones, so I can't be sure on that.

Is Batman in your mod too?

Not switch back-and-forth, just domination + delay kill.

ah.  I thought you were switching them back

Having them switch back just requires another ability.  You nest a self replacing passive onto all the ships, or in some sort of counter-measure ability, and have it trigger off the domination ability.  Temp conversion achieved.  Might do it for a Borg counter-measure, might be too lazy, not sure yet.

I don't even know if that is possible..  Is player index of firstSpawner saved at the time of usage or does calling playerIndex simply check the current playerIndex.

Yeah sorry bro. 

It's not only possible, it's a piece of cake.  In my case, I need to design a layered system of checks based on what type of assimilation ability has been used, instead of just using OwnerChanged and calling it a day.  To just make them all temporary is two files.

The ability and buff files for the "attraction" type ability I've been trying to get to work:

AbilityFRAND

BuffFRANDSpawner

BuffFRANDTarget

Trying to attract like magnetize, bring hostile ships to each other into a lump. At the moment all they do is slow down like slugs. Earlier discussion on pg 46.

Edit: Re-linked

Got a question to go with those links?

I'm finding that all three links link to the same thing, BuffRANDTarget.entity...

Well this is a little embarrassing as it is baby stuff and I am sure it's got to be a typo somewhere but...I've added some new planet types to the GSD and keep getting an error that results in a minidump.

The error on Rebellion start with the mod loaded is:

On actually trying to start a game with the mod loaded I get this:

After that error pops up, I get 

Here's the pastebin of the debug file: http://pastebin.com/b84UbMAN

Here's the mod GSD contents: http://pastebin.com/xGkryxDN

Here's a list of the new planets to make it easier: http://pastebin.com/XPpDLkMN

I didn't change existing planets or any other files aside from the GSD and the added new planet entries.  I didn't insert them in strict alphabetical order either (I don't think anyway)

Usually when I get an error in a file that I haven't touched it means a count is off or a line has been cut or space left open just before or just after it.

Just would like another eyeball--mine are tired and too multitasked right now. I've gone through and recounted entries and the like (I think it may be off some now after playing with changes but the errors remain the same throughout).

Just a thought Sinperium, but perhaps there is a hardcode limit on how many different planetTypes can reference the same orbitBodyType...it seems you have 7 planetTypes that use PlasmaStorm, and with just a quick glance the most I saw of any other planetType is 6....so, maybe 6 is a hard limit...

I'd say see if removing one of your plasma storm planetTypes fixes the issue...IIRC you had 6 gas giants so we know 6 works fine....

You have a whole mess of planet entities, but the references in GSD are for the vanilla entities.

Edit: DesignName is NOT the entity reference, OrbitBodyType sets the entity with EntityDefName.

@psychoak...I'm seeing my new ones in there.

Yeah Seleuceia..I remember someone on the DS team a long time ago saying Sins was picky about names--unfortunately they didn't elaborate.

The planets are all combinations that already occur in native vanilla.  The idea was to let people set up exact map reseources per planet without allowing combinations thaty don't already randomly occur--though it requires making custom maps.

As it turns out, Plasma Storm was the only one with seven variants.  I'll delete one and see what happens.

Thanks.

Sorry redone

They're in there, they simply have nothing at all to do with the entity file.  You're trying to use the design name to reference them.

onReapplyDuplicateType "PrioritizeNewBuffs"

instantAction
    buffInstantActionType "ResetPhysicsState"
    instantActionTriggerType "OnBuffFinish"

Every .5 seconds, BuffRANDTarget is replaced, triggering the reset to it's physics state.

I didn't want to add new string files at this point as they will essentially be identical in terms with the vanilla ones. I updated the manifest to be through ans as I might introduce new strings in the future.

Here's the update...

Taking Seleuceia's suggestion--since the Plasma Storm was the only one with seven variants--I deleted one variant of the Plasma Storm and deleted it's count and entries in the manifest and GSD.

Now it doesn't show a debug error or minidump.

So unless it's serendipity, apparently six variants of an orbit body type are all that's allowed.  If anyone has a better answer, I'd like to hear it as well.  I hate assuming.

On the other thing psychoak, you appear to be right.  I need to create string files for each then don't I?

No.  Your entity files aren't being used at all.  Those 45 new planets are folder decoration, nothing more.

Sinperium, I'm not exactly sure what your problem is, and I haven't looked at the file, but it doesn't sound like you know what you're doing. So in general this is what you have to do to the GSD to add a planet.

1. Add a entry in the OrbitBody section. There will be exactly one entry for every planet entity file you have. typeName is the name you will use to refer to it else where in the GSD. entityDefName is the name of the planet entity file. Both of these should be unique to each entry, you should not reference the same entity file or name more than once.

2. Using the new OrbitBodyTypes you created, add them to the various planetTypes, using the typeName. Here you can have multiple OrbitBodys, and reference OrbitBodys more than once if you want to give that body a better chance of appearing. When a map specifies a planet type, it will pick a OrbitBody at random from the list and spawn that planet entity file. There is no limit to the number of OrbitBodys you can have in a planetType.

If you are making new planetTypes, you should add new strings, but if you leave it blank it will only be noticeable in the map designer. They aren't used anywhere else.