System Spawn

[Nestharus]

In other words, you want me to make a spell object for making spell effects, an ability that can steal spells temporarily and a system for stealing the spells temporarily (would be relatively small as it wouldn't have to track anything) : |.

Can't I just tell you Spawn can easily do it? wait.. are you guys trying to get me to make all your stuff for you instead of you guys making it and submitting them as various systems that run with spawn?? >: O

Here's the blue print if anyone else wants to do it, asking someone to do it for me because I'm tired of making demos, lol. He'd submit it as his own resource tho ^_^.
First- make a spell that steals spells temporarily via a timer array. Add the spell as a spawn to a handle and then use spawn to store the timers. When a spell steals another spell, start the timer for however long it should be, remove the ability from the first unit, add the ability to the second unit, then do base.lendSpawn(spawn.id) using the id of the spell. You'll need to attach the spawn id to the timer.

When it reverts back, first get the handle owner of the spell via Handle(Base(spawn.base).base). The handle is stored using its id, so for this you need to know the handle type, which should always be a unit as you are dealing with spells, so do this, UnitHandle_data[Handle(Base(spawn.base).base)] if you are using my object ; P. Now do spawn.revert() or w/e, and then get the second unit UnitHandle_data[Handle(Base(spawn.base).base)], same code =). Remove the ability from the first unit and add it to the second.

Now, release the timer of the first unit since it is expired and then check to see if the second unit has a timer (is timer[spawn] null?). If it does, resume it.

You are done =).

Also, the ability should not be hard coded into the spawn. Let the person define their own abilities and pass in their data. Do not extend the spawn struct, just use your own internal arrays and let people modify the data for different levels of the ability. The ability is simply an interface. Finally, you should do a spell event for all players when that ability is cast for spawning that ability. It'd be pretty weird to make it timed =P, unless you like wanted to steal a random ability from a unit in range every x seconds.

 

[uberfoop]

I think the bigger reason is that all you've really convinvced people that it's good for are some manner of unit spawning systems plus spell stealing abilities, the former of which already exist in intuitive ways that people can actually understand and the latter of which people usually do not want to deal with, for reasons such as coding your entire map specifically to suit one ability is silly, or gameplay issues with such an ability.

In other words, you have to convince people that it's useful beyond "OMG LOOK AT THIS IT'S WICKED SICK COOL!"

Good luck doing that, by the way, since few people are going to look through your documentation AND code very thoroughly to start with if you don't; Word says the combined total of documentation and script is the equivalent of over 9500 words, which, were it Fantasy or Sci-fi literature, would be defined as a novelette by SFWA.

 

[Nestharus]

Spawn can do a lot... can I demo out everything spawn can do in every scenario? No. I can make demos for spawns various features, but if I made one demo for every one feature there'd be like 200 demos, which is why I've been merging the features together in the demos so that there are maybe 6 for some of Spawn's main features.

Asking me, "what can this be used for?" is a really dumb question. Use it for whatever you want.

When should you use it?

Whenever this relationship seems appropriate-
one handle - one to many spawns

Oh yes, and Spawn 4.0 is in the works with a lot of nifty features and performance boosts and bug fixes-

Better documentation and description
A demo map with a demo area where you can cnp demos
Major performance boosts
The ability to attach multiple bases to handles and the ability to attach the same base to multiple handles
The ability to attach a spawn to multiple bases
Algorithmic Placement (if you want to place a wisp wheel or something, if you have a spawnCount of 8 or w/e, it'll place it properly)
Mimicing will no longer bug when lending spawns on a base that's in mimic mode to another base and then reverting those spawns when the base leaves mimic mode.
Reverting will no longer bug up if the bases the spawns are reverting to no longer exist (even if you create a new base and it gets the same base id). They will be destroyed if they are sent to the original, or they will be sent back 1 extra step until it finds a base.

 

[Nestharus]

Ok.. so apparently somehow my description isn't showing up for Spawn in post 1 even tho it is def there... dunno what happened, but edited it and it's just not showing up anymore... hmm

So moving on-

Progress on v4.0

1. Handles with multiple bases and bases with multiple handles-
This is probably the most complicated feature being added into the Spawn 4.0 as a lot of stuff has to be updated to handle this =). So, how would this work?

When you attach a base to a handle, it'll attach it like the old spawn. If you try to attach a base to more than one handle, it'll convert the handles into a handle group internally without you the user having to do anything about it. When spawns are created etc, it references the handle group and loops through each handle in the group. This is slower than a single handle though as it has to do this. Whenever there is just one handle, it will convert it back to regular attachment if it's in handle group form or it'll just use a regular attachment (normal speed of current Spawn).

Because of the new handle groups, a base now requires the handle for its methods like transfer and trade. This is because if it has multiple handles, it doesn't know which handle to reference.

2. The next feature being worked on is better mimicing. What's wrong with the current mimicing? Well, it works, but a lot of bugs can rise up. Number 1... the base changes when it begins mimicing, so if you attached data to it using the base or w/e, it'll start pointing to the wrong spot. The new mimic will maintain current spawn and base id. Another issue is borrowing/lending... if you were to make a base mimic and then lend those spawns out, then stop mimicing, those spawns would still go back to the base. Now, when a base stops mimicing all of its spawns and what not are destroyed (only mimic ones), meaning there are a couple of new methods like destroyMimicSpawns and what not ^_^.

3. Ownership tracking is receiving some hefty updates. A current bug that can arise could be this-
Base 1 gets a spawn
Base 1 lends that spawn to Base 2
Base 1 is destroyed
A new base is created and is assigned with index 1
Base 2 reverts the spawn and the new base gets the spawn...

4.0 uses index ids that are never recycled to make sure that this does not happen. Base 1 will still be used again, but instead it'd look like this
Base 1 is created and base.id = 1
Base 2 is created and base.id = 2
Base 1 gets a spawn
Base 1 lends that spawn to Base 2
Base 1 is destroyed
A new base is created and is assigned to Base 1 with base.id = 3
Base 2 reverts the spawn. Base 1's id does not match 1, so the spawn stays at base 2 and the original owner changes.

In short, if the previous owners do not exist, it goes to the oldest owner and makes that the new original owner =). This is the default. If you want to destroy all owned spawns when you destroy a base, you can always do base.getBackSpawns() and then base.destroy() =P. If you want to use this new feature of oldest owner, then just do base.destroy() : D. Handles, bases, and spawns get these ids.

4. Spawns will now use special algorithms for placing spawns. This means if you have a spawn count of 8 but you want them to spawn in a circular fashion, it'll place the 8 spawns evenly in a circle =). I'm not sure yet how I'm going to really implement algorithms as there is no way I can use delegates or stub methods without a HUGE performance hit, but I will figure it out =D.

5. New properties for handles. Also, a handleId var was added so that instead of using handle.getHandleId(), you can use handle.handleId, which should be WAY fast as it's just an array look up vrs an evaluated trigger followed by GetHandleId().

My question is what other new features would you like to see in Spawn ^^.


still can't figure out a way to put in algorithms without the use of triggers : |

 

[Nestharus]

Posted up some of the new designs

Made it so people can join in on the design of 4.0 ^_^