[System]Spawn

[Nestharus]

What Previous Versions Had-
Spawn 1.0-
The ability to make any object mimic any other object, including units mimicing items
The ability to lend and borrow bases and spawns up to any degree
Easily trade spawns, etc
Spawn at the handle's x and y coordinates

Spawn 2.0
API Improvements and many performance enhancements

Spawn 3.0
Relative Spawning (spawn relative to x, y, and facing of handle and base spawn slot)
More performance improvements
Improved mimicing

Advanced Data Attachment
-Attachment Archiving
-Multi Data Attachment
-3 Levels of Data Attachment All With Multiple Attachments

Extensibility-
It uses a combination of interfaces and structs so that any type of variable or set of data can be used-

library MyHandle
    globals
        private unit array u
    endglobals

    public struct Unit extends Handle
        //sets up u and makes the getters and sets of the handle point to the unit array
        //and use unit getters/setters (SetUnitX and GetUnitX for example)
    endstruct
endlibrary

Flexibility-
Contains many delegates so that pieces of objects can be put together to create a full object. These pieces can all be changed at a whim!

Just to name a few-
Base- modifiers, custom method injections
Spawn- modifiers, algorithms, custom method injections, creation

Advanced Data Manipulation-
Cloning, Mimicing, trading between large sets of data, and so forth all with very simple calls!

Custom Data Attachment On Top Of Spawn's Architecture-
All Handles, Bases, and Spawns may be used as ids for attaching data in an array-
myArray[handle] = myData

For validation, all handles, bases, and spawns include an id that stays unique for the entire game. They also include a mimicId that stays unique for
entire game. The reason for the id is because struct ids get recycled-

if handle.id == myId[handle] then //make sure it's the same handle and that it's still in its state
    set myData[handle] = data
endif

The mimic id can be used if you only wanted to attach data to something for a specific instance of a mimic

Advanced Data Production so that Produced Data can be relative to any other piece of data up the tree-
Spawn Objects can produce any data you want. They use everything you plugged into them and then pass all of the data into a method you
write yourself.

Parameters: spawn, player, typeId, x, y, z, facing

The Spawn calls your function multiple times, so all you have to worry about is making the type, Spawn does the rest =).

local unit u = CreateUnit(player, typeId, x, y, facing)
call SetUnitFlyHeight(u, z, z*10)

JASS Description

Design Upgrades-
onBaseAdd/onBaseRemove
onSpawnAdd/onSpawnRemove
Modifier Object

UML Guide
Eclipse

ERD Guide Part 1
ERD Guide Part 2
MySQL Workbench

Progress-
1. Use Chart
2. Initial Class Chart
3. Sequence Diagram and map out the API
4. Write Spawn 4.0
5. Write out manual using the charts and API (very technical and in-depth) (for designers)
6. Release 4.0 as a beta and get feedback
7. Work on 4.1 if any features are requested or any bugs are found
8. Write a guide (for users)

MySQL Workbench File

 

[MapperMalte]

Wow, that's a lot of code.
But it doesn't compile.
When I get it to work, I'll check and read through the whole system.

You should give an example of how to use it and explain this library better.
Your description made me laugh, because it is very none-saying:

Spawn is used to group data together and attach the grouped data to
a piece of data and from there produce that group of data for the piece
of data

==> Means ?
Give an example in a test map.
xD

 

[Nestharus]

Oh... this current version requires a few things =).

You need the pools, which are at the top.. and the old pool script, which isn't around anymore.. I'm updating this right now Malte, lol, among other things.

But this thing is amazing : D. It can run anything ^_^, combat systems, spell systems, all of it : D.

 

[MapperMalte]

Then give examples.
And do not keep saying your systems are amazing, because they're often .. not amazing.

 

[Nestharus]

Update is up : D.

 

[MapperMalte]

But still no example.

 

[Nestharus]

Update-
Took the premade objects out of the code and put them in their own section
Added a "very" simple demonstration using the premade objects

 

[MapperMalte]

What makes your long and complicated code better than this:

http://peeeq.de/gui.php?id=1275

?

 

[Nestharus]

Maintainability...

Also, my long and complicated code can do a lot more than that... i provided a very simple example... that same unit handle could have been a system object and that same spawn object could have been another system object.

 

[MapperMalte]

´

Maintainability

Wrong. Mine can be changed as quickly as yours.
I can write that stuff 10 times in the time I need to write your stuff.

Then make a more complicated example, where you can show the power of this system.

 

[Nestharus]

What does my trade spawn demo demonstrate?
You can have multiple types in spawn and trade them all around very simply
You don't have to track spawns, and if you want to access all the spawns on a base and do something with them yourself, you can loop thru them using my loop tip.

Everyone says, I can hard code for the same effects, but can you really? My trade spawn demonstration showed that hard coding does not merit the same results in any way without you having to do a billion things, so why not let Spawn do it for you and save yourself the trouble... Spawn handles anything you want, so it's not like you can say I really need to handle this, and you can inject into it, so you can't really say I need to handle these extra things.

Also, Spawn can handle any type like I said, meaning you could spawn Bases which spawn additional spawns of the spawn. cloneSpawns will clone all spawns on a base and give them to a base.

There's really no comparison to, "hard code this" or "CreateUnit()" or w/e else people have come up with saying this is useless. The fact is Spawn tracks everything for you, automatically links up all your stuff with all the handle objects, and you can pretty much customize every aspect of Spawn without having to modify the system.

A final argument would be, if I need to spawn units, why not just use SUPOT... it's way easier.
What if you want to spawn units at a handle's coordinates... does SUPOT do that? I thought it took specific coords... so you'd have to update the coords every time. Does Spawn take specific coords? Yes, you can overwrite the coordinates in Spawn to be whatever you like.

But, I need to spawn units and just units. You know, there's a small snippet I made that does the exact same thing as SUPOT just as easily but gives you all the power of Spawn. It's 31 lines... it's called SU and it's in post 3. The only reason to use SU I suppose would be for very simple purposes, and then at that point, why would you even bother with a system. If you don't care about your maintainability or extensibility, then you should just hard code it -.-.

Spawn works for any given need, and systems that are built with Spawn like projectile systems will automatically inherit all of Spawns features and tracking like work on all types and lend, borrow, clone, mimic, etc.

My question is, if you are going to make a system or a map and you aren't planning on hard coding everything, then why shouldn't you use Spawn for all your data producing needs??

 

[YourNameHere]

Why don't you use stub methods instead of interfaces at some points? Might be alot handier.

 

[Nestharus]

Spawn needs to be able to access basic handle data in order to run, hence the interfaces ^_^. Also, a struct with empty stub methods sounds silly ; ).

Where would you suggest stub methods be?


Oh, btw, here are some updates that are included in the various thingies-
Spawning in 3.0 is epic. It can spawn with offsets and relatives and so on : D. Spawning is also based on the facing of the handle. Spawn offsets can be put into the base's spawn array with spawn ids and or the spawn properties =). None, one, or both can be used, and they can all either be direct or relative to the base's handle position! Spawn properties can also be relative to the base's coordinates for the spawn id it's in! It is very spiffy ^^.

The item object was extensively updated to work when the item is being carried by a unit : O.

Life is good =).

 

[YourNameHere]

Spawn needs to be able to access basic handle data in order to run, hence the interfaces ^_^. Also, a struct with empty stub methods sounds silly ; ).

Where would you suggest stub methods be?

ah no I mislooked, I thought that those functions in the Base and Spawn structs where just methods from the interface. Guess it was too early in the morning when I checked this

 

[MapperMalte]

Could you please add comments to the code and make a better description?
And really, I still don't see an example that shows the power of this/that can't be hardcoded easily. And I will keep thinking that this is useless until you make such an example.

 

[Nestharus]

Working on 4.0 =)
4.0 includes-
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.

And MapperMalte, no, I'm not adding comments to the code. It's long enough as it is, and if I added comments it probably wouldn't fit into the hive. I'll probably have to remove the debug statements to keep it fitting.

If you want to try to understand some of the complicated indexing involved in Spawn, go ahead ^_^.

 

[MapperMalte]

Why do you release version 4.0 after two days? Why don't you just finish a system before submitting it?

 

[Nestharus]

This is finished, lol. I increase the version number when I add various methods. I increase the build when it's pure internal.

I'm adding some extensive new features to this and fixing a design flaw with mimic that would screw up the indexing.

 

[MapperMalte]

I increase the version number when I add various methods

Then stop writing 'major' performance boosts into all your changelogs.
If you don't make a proper documentation, most people won't read this.

 

[Nestharus]

4.0 includes rewritten documentation mate ; )

And current documentation does document everything =).

 

[Element of Water]

MapperMalte, stop being an arsehole. You're just trying to find every possible way to slag off Nestharus...

 

[Nestharus]

Spawn 4.0 is in development

Development Specs and progress are posted up and everyone is welcome to join in to make Spawn 4.0 the best data utility for wc3 =).

Everyone will get credit for helping out (authors will be all of us) ^_^.

 

[MapperMalte]

You know, why I especially post flak on your systems?
Because you always praise them and write 'they are so good. So many features'.
Dude, spend the time writing a proper description.

This sentence:

Spawn is a utility used to attach ambiguous data to other ambiguous data as well as produce data for given data relative to given data.

Helps absolutely nothing.
What can I do with this?
Spawn trees and units with one struct?
Each normal person can describe things well.
Give an example in an example map!

Why would I like to lent and borrow IDs and set units xs and ys just to spawn units?
Here:

http://www.engl.niu.edu/wac/descr_how.html

Read that!
And then remake the description.

Oh, and I can't actually see real code.
And I can't open the file you posted.

Sorry for being harsh.
But it simply drives me crazy.


edit: I got an idea. You give me an example map and the code, and I qrite the description for you.

 

[Nestharus]

Sure MapperMalte : )

ERD still needs work , meaning I gotta reprogram some of the stuff I wrote, bah ><.

First I gotta get 4.0 pumped out tho =P.

I can explain it in JASS tho for you ^_^, that's very easy for me to do-

1. Has a private Handle Prototype interface that the system uses internally
2. Has a public struct called Handle that extends Handle Prototype and adds a few methods. Users extend upon this. From here, users do something like this-

library MyHandle
    globals
        private unit array u
    endglobals

    public struct Unit extends Spawn_Handle
        //sets up u and makes the getters and setts of the handle point to the unit array
        //and use unit getters/setters like SetUnitX and GetUnitX
    endstruct
endlibrary

From here, users can sort of write ambiguous code by using Spawn's Handle Interface and the basic handle properties and methods, which are in post 1.

Users can write more specific handles, for example they could add GetLife and SetLife for a user defined widget struct. In this way, a handle tree is made =), sorta like the one in JASS except that properties can be put at the very top =P, like all handles could be given coordinates so that they work in Spawn.

At this point, you have handle groups. These group handles up together.

Next, you have a base. A base is the primary data manipulator thingie =P. Bases are not extended upon, only created. Bases are put into baseGroups, which group up bases.

1 handle group takes 1 baseGroup (1:1)

many handles go into a handle group
Handles go into many groups

Many bases go into a baseGroup
Bases go into many groups

Groups are completely private, so to the user it looks like magic =P.

So this means that the HandleGroup struct just points to a baseGroup struct, and inside of the structs is a hashtable that acts as an array member =).

Bases contain most of the methods, like engraveSpawn, addSpawn, attach, etc, etc.

So, so far it looks like a very intricate data attachment system that can sort of attach ambiguous types by wrapping up variables with structs and putting them through an interface.

But it can do more. There are borrow/lend methods, which means exactly what they do. If you were to transfer a base from one baseGroup to another baseGroup, you could do it normally with what is called a transfer method. This just removes the base from the first baseGroup and attaches it to the second baseGroup. Pretty normal =). If you were to "lend" it from one baseGroup to the other baseGroup, it would create a lentBase, which is just something that records the borrower, the lender, and the base in question.

The lent base group is accessed with a lentBaseID. From here, two more records are made into hashtables-
call SaveInteger(borrower, borrowerBaseGroupID, arrayIndex, lentBaseID)
call SaveInteger(lender, lenderBaseGroupID, arrayIndex, lentBaseID)

struct lentBase
public integer lenderBaseGroupId
public integer borrowerBaseGroupId
public integer baseLentIndex
public integer baseId
endstruct

set baseLentIndex = baseLentIndex + 1 //whenever lending

This way both the borrower and the lender can access the lentBaseID. Also, both can retrieve exactly where the lender stands for the lentBaseGroup (how many steps back you have to go to get to it).

I call this ownership tracking, more accurately attachment tracking. It allows you to do what I call reversion, or go back to previous remove a base from a current baseGroup and attach it to a previous one. It can go all the way back to the first baseGroup that it was attached to.

Furthermore, you need a unique hashtable, which records the first time a baseGroup had a unique base. This table is used for what is called the getBack method. It just records the lent record.

call SaveInteger(uniqueBase, baseGroupID, Index, lentBase)

Groups are not lent between groups because they have a 1:1 relationship, and users can't mess with groups anyways.

Spawn's work in much the same way for SpawnGroups, lentSpawns, and what not. Spawns go into SpawnGroups and a SpawnGroup goes into a BaseGroup in a 1:1 relationship : |.

Spawn objects are used to make things on the map, like effects or units or w/e. They have a trigger and a timer which both have a function on them for making stuff (static method in the Spawn Object). They also have an interface delegate with a make method in it. You set the delegate to what you are making.

The make method looks like this-

    public method make takes Spawn spawn, player p, integer typeId, real x, real y, real z, real facing returns nothing
    endmethod

The Spawn passes in all the require components, so all you would have to do is something like this-
CreateUnit(p, typeId, x, y, facing)

Furthermore, the Spawn runs through everything it is attached to. Also, it retrieves all the unique coordinates. Bases can have offsets for certain spawn slots or direct ones (like handleX + 100 or just 100) and Spawns can have Handle Offsets and or Base Offsets or direct ones (HandleX + BaseOffset + SpawnOffset). In this way, the passed in data (x, y, facing) can be completely relative to the handle (spawn at the handle with the same facing or spawn 200 in front of the handle based on the facing or w/e else). Also, Spawns can take an algorithm data. An algorithm takes the coordinates and facing-

    public method algorithmX takes Spawn spawn, integer current, real x, real y, real z, real facing returns nothing
        set spawn.x = x + (current*50)
        set spawn.y = y + (current*50)
        set spawn.z = z
        set spawn.facing = facing
    endmethod

Current would be the current spawn that is spawning. For example, if a spawn had a spawnCount of 20, the current would be 1-20. The above algorithm would just make a diagonal line =P. The spawn would use the variables it sets =). You could also make a circle algorithm, or a cube algorithm, or w/e else you want. You could even attach data to a spawn in the algorithm using the Spawn struct (spawn is passed in remember).

From here, handles, bases, and spawns can mimic other handles, bases, and spawns. Handles could mimic any combo (handle, base, spawn, a set, or all). Base can do any combo (base, spawn, or both), and a spawn can mimic a spawn.

To give a pretty simple example-
Handle 1- Paladin
Base 1- base1
Spawn1 - Boots of Speed

Handle2- Orb of Darkness
Base 1- base2
Spawn2- Peasant

If Handle1 were to mimic Handle2 it could be-
Handle1- Orb of Darkness
Base1- a copy of base2
Spawn1- Peasant

It does a completely and full deep mimic, copying everything. it could also just be-
Handle1- Orb of Darkness
Base1- base1
Spawn1- Boots of Speed

or
Handle1- Paladin
Base1- base1
Spawn1- Peasant

or whatever order you want : o.

So that's mostly what Spawn does =)

 

[MapperMalte]

Perfect!
That's a nice description.
Now I understood why this is actually useful.
Well, I must say, that is a nice concept and seems useful.
I will test it in the next days and post explicit feedback.

 

[Nestharus]

Mapper, you still have 3.1 and an older version of Recycle? : O

 

[aznricepuff]

I still don't see proper documentation for this. Moreover I can't see the code for this anywhere. And please remove that huge image in your original post. It's not very descriptive anyway and it's just taking up space.

Btw, your "JASS description" doesn't really help. Basically I got three things from it:

You provide an interface to help people make wrapper structs for handles (and how exactly the interface helps I don't know because I can't find the actual code).

You provide methods for people to move around said wrappers amongst various groups.

You have something called a spawn that can "spawn" things.


I have no idea what "bases" are used for, and therefore by corollary I have no idea what lending and borrowing bases do. I have no idea what mimicing is supposed to achieve either.

From what I can see right now, this could be something that is extremely useful ... or it can be a pile of worthless code. I simply can't tell because I don't have access to any proper documentation or the source code (though I would prefer reading proper documentation over sifting through a bunch of code).

 

[Nestharus]

I'll give the 3.1 API.

This API will not be the same in 4.0.

This API might give you a better idea as to what Spawn has been able to do.

4.0 will be able to do everything here better and faster, and it will be able to do more =).

Ok, and to answer your questions-

I have no idea what "bases" are used for, and therefore by corollary I have no idea what lending and borrowing bases do. I have no idea what mimicing is supposed to achieve either.

1. Bases are like groups for spawns. They manipulate all spawns attached to them =). Spawns also interface with bases to get handle properties. In essence, the handle that the base is attached to would be the x and y coords for all spawns attached to that base. In 4.0, this moves to groups (spawnGroups, baseGroups, and possibly handleGroups). Each group interfaces with each other group in a 1:1 relationship =P. In this way, attachments can more easily be tracked (more maintainable for me =p).

2. Lending and Borrowing Bases is like transferring a base while maintaining the original owner.

Handle1 lends Base1 to Handle2
Base1 is attached to Handle2 (not Handle1)
Handle1 is still the owner

Handle2 lends Base1 to Handle3
Base1 is now attached to Handle3 (not Handle2)
Handle2 is now the secondary owner and Handle1 the first

Handle3 reverts the spawn
Spawn is now attached to Handle2 (not Handle3)

-or-

Handle1 gets back its spawns
Spawn is now attached to Handle1 and the other handles lose secondary ownership

-or-

Handle2 gets back its spawns
Spawn is now attached to Handle2 and Handle3 loses secondary ownership

Meaning that lend is like transferring a spawn and recording it =P. This means that it can be reverted from the current attachment all the way to the first =).

3. Mimicing is where one thing mimics another thing.... what's there to understand?

If handle1 is a Paladin and handle2 is a Boots of Speed and handle1 mimics handle2, handle1 will now be Boots of Speed?

What's hard about that?

If handle1 stops mimicing, it'll go back to a Paladin O-o.

Are you asking me that you don't understand that, or that you don't get how the hell I'm doing it without even knowing the objects people make : o.

Well, if you are asking how, it's very easy. Remember interfaces? I get these-

getX
getY
getZ
getPlayer
getFacing
getTypeId
make
clean
remove (4.0)

So... I can easily make any object without knowing wth it is all with the same code =P.

1. Store x, y, z, facing, and typeId
2. Remove it from the map
3. Change the type if the type's don't match =P
4. make using the x, y, z, facing, and typeId of the handle to be mimic'd
5. Done =D

And to stop mimic, just restore the stored up values =p.

Now in 4.0, it's clever with how it does this =). If you look at the ERD, you will see-

Internal Handle (returns one of two possible values)
External Handle (points to internal)

With this setup, we can then do this-
1. Create a new handle
2. External handle points to new handle (delegate)
3. Store previous handle into new handle
4. Remove the representation of the internal handle (like RemoveUnit())
5. Get the typeId, x, y, z, and facing of the handle to be mimic'd and make =P


Faster, better, cooler =). 3.1 didn't do what I described, it did the second method but without an external handle. What this meant is that if you had attached data, it'd be ruined because the struct instances would change : (.

There's also some other stuff, but at that point I'd be really getting into the inner workings of Spawn 4.0 =).


So in finality, when you xfer a base from one handle to another, it's like transferring all of its spawns from that one handle to another (but faster as it only needs to work with one pointer instead of many).

So why is this system useful?
1. Users can work the same code for many types
2. The awesome mimicing =P
3. Manipulating large amounts of data quickly and efficiently (talked about some of this above)
4. Producing any type of data easily and piecing objects together to make unique objects of the user's design without the coder having to make 30000 dif things with small changes or the user having to go thru the code =P.
5. Fast attachment and handleId
6. Shall I even go on? : P

And let's get creative with what exactly a spawn might be-
1. Poison effect on a unit?
2. An attack (remember algorithms?)

And what about Handles?
1. A multitude of spawns? (remember handles can store anything!!)

What else could happen?
1. Spawns could spawn bases or handle objects?

Really, there's just so much you can do with this =). It's not at all limited to spawning footmen. I've only ever used that in examples because that was the simplest implementation =).

And Spawn 4.0 can just do so much more, all with the same exact code (no extra coding). It's ambiguous enough that it works basic snippets on everything =).

Why did I make it?
So I didn't have to make things like lend and mimic for every type. Not only would that be a huge amount of code, but that would be stupid =P.

3.1 API

/*
Variables and Custom Method Injection:
------------------------------------------------------------------
Hashtables-
    Spawn_memory: stores handle structs with the HANDLE key
        (Spawn_memory, Spawn_HANDLE, GetHandleId(handle), integer id)
    
keys-
    Spawn_DATA- used for storing custom data
    Spawn_SPAWN- used for storing spawns
    Spawn_CONTAINER_BASE- used for storing containers in mimicing bases
    Spawn_CONTAINER_SPAWN- used for storing containers in mimicing spawns
    Spawn_OWNERS- used for storing base owners (handle struct ids)
    Spawn_LENT- used for storing handle struct ids for lent bases
    Spawn_BORROWED- used for storing handle struct ids for borrowed bases
    Spawn_LENT_SPAWN- used for storing base struct ids for lent spawns
    Spawn_BORROWED_SPAWN- used for storing base struct ids for borrowed spawns
    Spawn_BASE- used for storing bases in handles
    Spawn_STEPS- used for tracking steps on borrowed/lent spawns/bases
    Spawn_BORROWED_SPAWN_TYPE- used to store spawn
    Spawn_BORROWED_SPAWN_TYPE_R- used to store base
    Spawn_FIRST_BORROWED_SPAWN- used to record the steps for when a spawn was first on base
    Spawn_HANDLE- used in spawn memory hashtable for storing handle structs
    Spawn_X- used for storing custom x coordinate data in bases for attached spawns to use instead of base x coord
    Spawn_Y- used for storing custom y coordinate data in bases for attached spawns to use instead of base y coord
    Spawn_RELATIVE_X- used for making the x coordinate data relative or not.
    Spawn_RELATIVE_Y- used for making the y coordinate data relative or not.
    Spawn_TRIGGER- used to store data for spawn triggers using the trigger handle id
    
Spawn- extend Spawn for your Spawns and SpawnPrototype for making entirely new Spawns
    public Spawn_Spawn container: a container holding the spawn when mimic mode is on
    public timer t: the spawn timer
    public integer base: the base the spawn is attached to
    public integer ownerIndex: refers to how many owners the spawn has
    public hashtable memory: a memory hashtable
    public boolean mimicing: is the spawn mimicing or not
    public real spawnTime: spawn time of spawns
    public integer spawnType: spawn type of spawns
    public integer spawnCount: spawn count of spwans
    public trigger spawnEvent: trigger (call TriggerAddAction(spawn.spawnEvent, function MyFunc)
    public integer id: refers to the spawn's id for the base it's attached to. Use this id to use base methods that
        manipulate specific spawns that are already on the base.
    public boolean override
        refers to whether or not the spawn will override the base and use it's xCoord and yCoord
    public real xCoord: refers to a spawn x coordinate for making a spawn
    public real yCoord: refers to a spawn y coordinate for making a spawn
    public boolean relativeCoordX: refers to whether the spawn will use the base's spawn x coord for the spawn's id in
                            in conjunction with its own spawn coordinates or not if override is true.
    public boolean relativeCoordY: refers to whether the spawn will use the base's spawn y coord for the spawn's id in
                            in conjunction with its own spawn coordinates or not if override is true.
    public boolean relativeX: makes spawn relative to the handle's x coordinate and facing that the base is
                       attached to.
    public boolean relativeY: makes spawn relative to the handle's y coordinate and facing that the base is
                       attached to.
    public delegate SpawnObject spawnHandle: Type of spawn
        extends SpawnObject
    public delegate SpawnMethod methodType: custom methods
        extends SpawnMethod
        
Base- extend Base for your Bases and BasePrototype for making entirely new Bases
    public real facing: initial handle facing
    public Spawn_Base container: refers to the base when mimic mode is on
    public integer typeId: refers to the type id of the handle of the stored unit
    public delegate Handle base: refers to the handle the base is attached to
    public integer spawnIndex: how many spawns the base has. A spawn stored in index 0 will make the base index 1. Spawns are stored sequentially
    public integer ownerIndex: how many handle owners the base has
    public integer lentIndex: how many spawns the base has lent out
    public integer borrowedIndex: how many spawns the base has borrowed
    public integer borrowedSpawnTypeIndex: how many unique spawns the base has borrowed
    public boolean mimicing: is the base in mimic mode
    public hashtable memory: memory hashtable
    public hashtable memorySpawnLent: stores lent spawns
    public hashtable memorySpawnBorrowed: stores borrowed spawns
    public delegate BaseMethod methodType: custom methods
        extends BaseMethod
        
SpawnObject-
    Refers to the type of spawn. This interface contains one method called make
    for making spawns.
    
SpawnMethod-
    Refers to custom methods. These structs are set into methodTypes on spawns
    to change custom methods on those spawns.
    
BaseMethod-
    Refers to custom methods. These structs are set into methodTypes on bases
    to change the custom methods on those bases.
    
Handle-
    Refers to handle types. This struct has many methods for retrieving and
    setting various attributes on given handles.
------------------------------------------------------------------

Functions:
------------------------------------------------------------------
Spawn_GetBase(handle)
    returns the base attached to the handle.
    
Spawn_GetHandle(handle)
    returns the internal handle id for the handle. Use with Handle interface.
    
Spawn_HasBase(handle)
    checks whether or not the handle has a base attached to it.
    
Spawn_HasHandle(handle)
    checks whether or not the handle is in the system.
    
Spawn_GiveBase(handle1, handle2)
    handle1 gives its base to handle2. Be sure to use HasBase to
    make sure that handle1 doesn't already have a base. Handles may
    only have one base on them or bugs will occur.
    
Spawn_TakeBase(handle1, handle2)
    handle1 takes the base attached to handle2. Be sure to use HasBase to
    make sure that handle1 doesn't already have a base. Handles may
    only have one base on them or bugs will occur.

Spawn_TradeBase(handle1, handle2)
    handle1 and handle2 trade bases.
    
Spawn_EnableHandleSpawns(handle, boolean restart)
    Enables all spawns on the handle. If restart is true, it
    will restart their timers. If restart is false, it will
    simply resume them. Restart only applies to spawns with a time
    greater than 0.
    
Spawn_EnableHandleSpawn(spawnId, handle)
    Enables a specific spawn on the handle. Use spawn.id
    
Spawn_TradeSpawns(handle1, handle2)
    Makes the handles trade spawns with each other.
    
Spawn_BorrowBase(handle1, handle2)
    handle1 borrows a base from handle2. Be sure to use HasBase to
    make sure that handle1 doesn't already have a base. Handles may
    only have one base on them or bugs will occur.
    
Spawn_LendBase(handle1, handle2)
    handle1 lends its base to handle2. Be sure to use HasBase to
    make sure that handle1 doesn't already have a base. Handles may
    only have one base on them or bugs will occur.
    
Spawn_GetBackBase(handle)
    handle gets its base back if it has a base lent out. Be sure to use HasBase to
    make sure that handle1 doesn't already have a base. Handles may
    only have one base on them or bugs will occur.
    
Spawn_RevertBase(handle)
    handle reverts its base. This may bug because handles may only have
    one base attached to them.
    
Spawn_OriginalBase(handle)
    handle sends the base attached to it back to the original owner. This
    may bug because handles may only have one base attached to them.
    
Spawn_Replace(handle, integer typeId)
    will change the handles typeId into the specified type, like changing a
    paladin into a peasant.
    
Methods:
------------------------------------------------------------------
Spawn_Handle-
    For Spawn to work, it must have atleast one handle defined-
    struct bleh extends Spawn_Handle
    endstruct

    Creating handles requires a good knowledge of vJASS. There is one
    premade handle for Spawn which can be modified for your use or looked
    upon for inspiration.
    
    vars:
        public integer h
            refers to the id of the handle
        public hashtable memory
            for memory storage
    
    methods:
        public method getMana takes nothing returns integer
        public method getX takes nothing returns real
        public method getY takes nothing returns real
        public method getPlayer takes nothing returns player
        public method getTypeId takes nothing returns integer
        public method getLife takes nothing returns real
        public method getLevel takes nothing returns integer
        public method getXP takes nothing returns integer
        public method getFacing takes nothing returns real
        public method getItem takes integer slot returns item
        public method getCharge takes integer slot returns integer
        
        public method setX takes real x returns nothing
        public method setY takes real y returns nothing
        public method setCharge takes integer slot, integer charge returns nothing
        public method setItem takes integer slot, item i returns nothing
        public method setMana takes integer value returns nothing
        public method setPosition takes real x, real y returns nothing
        public method setPlayer takes player p returns nothing
        public method setTypeId takes integer t returns nothing
        public method setLife takes real x returns nothing
        public method setLevel takes integer x returns nothing
        public method setXP takes integer x returns nothing
        public method setFacing takes real x returns nothing
        public method make takes player p, integer typeId, real x, real y, real facing returns nothing
        public method getHandleId takes nothing returns integer
        public method clean takes nothing returns nothing
        public method change takes integer typeId returns nothing
        
Spawn_SpawnObject-
    Spawn objects are used to determine what a spawn produces.
    
    methods:
        public method make takes player p, integer typeId, real x, real y, real facing, Spawn spawn returns nothing
            called for making a spawn.
        
Spawn_BaseMethod-
    Base methods are used for custom method injection into bases.
    
    methods:
        public method modify takes integer b, integer s, integer addRemove returns nothing
            called when spawn is added or removed to base. addRemove will be 1 for add and -1 for remove.
            integer b refers to the base that the spawn is attached/removed
            integer s refers to the spawn (convert to Spawn unless you are using custom variables and know
                what you are doing)
            
        public method mimicSpawnsCustom takes integer mimicBase, integer thisBase returns nothing
            called when base mimics the spawns of another base. mimicBase is the base to be mimic'd and
            thisBase is the mimicing base.
            
        public method stopMimicSpawnsCustom takes integer b returns nothing
            called when base stops mimicing spawns. integer b is the base.
            
        public method mimicCustom takes integer mimicBase, integer thisBase returns nothing
            called when base mimics another base. mimicBase is the base to be mimic'd and thisBase is
            the mimicing base.
            
        public method stopMimicCustom takes integer b returns nothing
            called when base stops mimicing another base. b is the mimicing base.
            
        public method cloneCustom takes integer b, player p, real x, real y, real facing returns nothing
            called when base is cloned. b refers to the base being cloned, p refers to the player it's
            being cloned for, x and y refer to the coordinates and facing refers to the facing.
            
        public method createNew takes integer b returns nothing
            called when base is created. b is the base being created.
            
        public method destroyCustom takes integer b returns nothing
            called when base is destroyed. b is the base being destroyed.
            
        public method cloneDataCustom takes integer b returns nothing
            called when base clones its data. b is the base being cloned.
            
        public method stopMimicHandleCustom takes integer b returns nothing
            called when base stops mimicing a handle. b is the mimicing base.
            
        public method mimicHandleCustom takes integer mimicBase, integer thisBase returns nothing
            called when base mimics the handle of another base. mimicBase is the mimic'd base and thisBase is
            the mimicing base.
            
        public method startMimicCustom takes integer thisBase returns nothing
            called when a base starts to mimic. thisBase is the mimicing base.
            
Spawn_SpawnMethod-
    Spawn methods are used for custom method injection into spawns.
    
    methods:
        public method createNew takes integer s returns nothing
            called when spawn is created. s refers to the created spawn.
            
        public method cloneCustom takes integer clone, integer thisSpawn, integer b returns nothing
            called when spawn is cloned for base. clone refers to the cloned spawn, thisSpawn refers to the
            spawn being cloned and b refers to the base the clone is going to.
            
        public method mimicCustom takes integer mimicSpawn, integer thisSpawn returns nothing
            called when spawn mimics another spawn. mimicSpawn is the mimic'd spawn and
            thisSpawn is the mimicing spawn.
            
        public method spawnAction takes player p, integer spawnType, real x, real y, real facing, Spawn spawn returns nothing
            called whenever a spawn spawns. p refers to the player it's being made for, spawnType
            refers to spawnType like unitTypeId, x and y refer to the coords, facing refers to the
            facing and spawn refers to the spawn that's being made. Only called if the spawn has a SpawnMethod.
            
        public method destroyCustom takes integer s returns nothing 
            called when a spawn is destroyed. s is the spawn being destroyed.
Spawn_Base
    Bases are groups of spawns and are attached to handles. They are like
    the data of the handle they are attached to. The reason handles and bases
    aren't combined is so that base data can easily be moved from one handle to
    another.
    
    methods:
        public static method create takes nothing returns Base
            creates a new base
            
        public method attach takes integer u returns nothing
            attaches a base to a handle struct. u is the handle struct id.
            
        public method isAttached takes nothing returns boolean
            checks whether or not a base is attached to a handle struct.
            
        public method transfer takes integer u returns nothing
            transfers a base from one handle struct to another. u is the
            handle struct the base is to be sent to.
            
        public method trade takes handle u returns nothing
            makes the base trade places with the base attached to handle u.
            
        public method swap takes integer b returns nothing
            makes the base swap places with base b.
            
        public method lend takes integer u returns nothing
            makes the handle struct lend its base to another handle struct.
            integer u is the handle struct to recieve the base.
            
        public method setSpawnX takes integer spawnId, real x, boolean relative returns nothing
            Sets the x coordinate for any spawn put in the spawnId. Relative will make the coordinate
            relative to the handle's x coordinate and facing that the base is attached to.
            
        public method setSpawnY takes integer spawnId, real y, boolean relative returns nothing
            Sets the y coordinate for any spawn put in the spawnId. Relative will make the coordinate
            relative to the handles y coordinate and facing that the base is attached to.
            
        public method setSpawnRelativeX takes integer spawnId, boolean relative returns nothing
            Will make the coordinate relative or not to the handle's x coordinate and facing that 
            the base is attached to for any spawn put in spawnId.
            
        public method setSpawnRelativeY takes integer spawnid, boolean relative returns nothing
            Will make the coordinate relative or not to the handles y coordinate and facing that 
            the base is attached to for any spawn put in spawnId.
            
        public method setSpawnCoordinates takes integer spawnId, real x, boolean relativeX, real y, boolean relativeY returns nothing
            Does everything that calling setSpawnX and setSpawnY would do. Better to use this if you are doing both
            
        public method disableSpawn takes integer s returns nothing
            disables a spawn on the base. s refers to spawn.id, not spawn
            
        public method enableSpawn takes integer s, boolean restart returns nothing
            enables a spawn on the base. restart determines whether or not the timers
            will restart on the spawn if the spawn has a time greater than 0.
            s refers to spawn.id, not spawn
            
        public method engraveSpawn takes integer s returns nothing
            adds a spawn to a base. s refers to the spawn
            
        public method degraveSpawn takes integer s returns nothing
            removes a spawn from a base. s refers to the spawn.id
        
        public method unsetSpawnOwner takes integer s returns nothing
            unsets a spawns owner without removing spawn. s refers to the spawn
            
        public method enableSpawns takes boolean restart returns nothing
            enable all spawns on a base. restart determines whether or not
            the timers on the spawns will restart or resume. restart
            only effects spawns with a spawn time greater than 0.
            
        public method disableSpawns takes nothing returns nothing
            disables all spawns on a base.
            
        public method remove takes nothing returns nothing
            removes a base from the handle struct it is currently
            attached to and disables all spawns for safety.
            
        public method original takes nothing returns nothing
            sends the base to its original handle struct owner.
            
        public method revert takes nothing returns nothing
            sends the base to the previous handle struct owner.
            
        public method revertTo takes integer s returns nothing
            sends the base back an amount of steps. s refers to the
            amount of steps. 1 step is like a regular revert.
            
        public method new takes integer typeid, player p, integer typeId, real x, real y, real facing returns nothing
            creates a new handle struct for the base and attaches the base to it. It also places
            the handle on the map.
            
        public method putSpawn takes integer s returns nothing
            attaches a spawn to a base without setting spawn owner. s refers to the spawn
            
        public method retireSpawn takes integer s returns nothing
            removes a spawn from the base without unsetting owner. s refers to spawn.id
            
        public method setSpawnOwner takes integer s returns nothing
            sets the owner of a spawn without attaching the spawn. s refers to the spawn
            
        public method degraveSpawns takes nothing returns nothing
            removes all spawns from the base.
            
        public method addSpawn takes Spawn s returns integer
            adds a clone of a spawn to the base. s refers to the spawn to be cloned.
            
        public method removeSpawn takes integer s returns nothing
            removes a spawn from a base and destroys it. s refers to spawn.id
            
        public method clearSpawns takes nothing returns nothing
            remove and destroy all spawns on a base.
            
        public method giveSpawn takes integer s, integer b returns nothing
            gives a spawn on base to another base. s refers to spawn.id and b refers to the base
            to recieve the spawn.
            
        public method giveSpawns takes integer b returns nothing
            gives all spawns on base to another base. b refers to the base
            to recieve the spawns.
            
        public method takeSpawn takes integer s, Base b returns nothing
            takes a spawn from a base. s refers to the spawn.id and b refers to the
            base to give lose its spawn.
            
        public method takeSpawns takes Base b returns nothing
            takes all spawns from a base. b refers to the base to lose its spawns.
            
        public method lendSpawn takes integer s, Base b returns nothing
            lends a spawn to a base. s refers to spawn.id and b refers to the base
            to recieve the spawn.
            
        public method lendSpawns takes integer b returns nothing
            lends all spawns to a base. b refers to the base to recieve the spawns.
            
        public method borrowSpawn takes integer s, integer b returns nothing
            borrows a spawn from a base. s refers to the spawn.id and b refers to the
            base to lose the spawn.
            
        public method borrowSpawns takes Base b returns nothing
            borrows all spawns from a base. b refers to the base to lose the spawns.
            
        public method revertSpawn takes integer s returns nothing
            sends a spawn back to its previous base owner. s refers to spawn.id of the spawn.
            
        public method revertSpawnTo takes integer s, integer steps returns nothing
            sends a spawn back an amount of steps. s refers to the spawn.id of the spawn
            and steps refers to the amount of steps.
            
        public method revertSpawns takes nothing returns nothing
            sends all spawns on base back to previous owners (1 step)
            
        public method revertSpawnsTo takes integer steps returns nothing
            sends all spawns on base back an amount of steps.
            
        public method originalSpawn takes integer s returns nothing
            sends the spawn back to its original owner. s refers to the spawn.id
            
        public method originalSpawns takes nothing returns nothing
            sends all spawns on the base back to their original owners.
            
        public method getBackSpawn takes Spawn spawn returns nothing
            gets a spawn back. spawn refers to the spawn.
            
        public method getBackSpawns takes nothing returns nothing
            gets back all spawns.
            
        public method tradeSpawn takes integer s, integer s2, Base base returns nothing
            trades a spawn for a spawn on another base. s refers to the spawn to be traded
            away and s2 refers to the spawn to be traded for. base refers to the other base.
            s and s2 both use spawn.id
            
        public method tradeSpawnAll takes Base base returns nothing
            trades all spawns on base for all spawns on another base. base refers to the other
            base.
            
        public method cloneSpawns takes integer b returns nothing
            clones all spawns on base b and engraves them to base.
            
        public method cloneData takes nothing returns integer
            clones data of base (the base and various vars) and
            returns cloned base.
            
        public method clone takes player p, real x, real y, real facing returns integer
            deep clones a base for a player at coords x, y with a facing and
            returns the cloned base. The handle is also cloned.
            
        public method startMimic takes nothing returns integer
            puts a base in mimic mode. While in mimic mode, all
            things that effect a base can be reversed. Nothing
            is permanent.
            
        public method mimicSpawns takes integer b returns integer
            mimics spawns on base b and puts base into mimic mode.
            
        public method mimicHandle takes integer b returns integer
            mimics handle on base b and puts base into mimic mode.
            
        public method mimic takes integer b returns integer
            mimics base b entirely and puts base into mimic mode.
            
        public method stopMimic takes nothing returns integer
            takes base out of mimic mode and puts it back to the
            state it was in before it went into mimic mode.
            
        public method stopMimicHandle takes nothing returns nothing
            changes base handle back to its original handle but
            does not take the base out of mimic mode. In essence, 
            the base mimics its own handle.
            
        public method stopMimicSpawns takes nothing returns nothing
            change base spawns back to original spawns but does
            not take the base out of mimic mode. In essence,
            the base mimics its own spawns.
            
Spawn_Spawn
    spawns are what bases produce
    
    methods:
        public static method create takes nothing returns Spawn
            creates a spawn
            
        public method isAttached takes nothing returns boolean
            checks to see if spawn is attached to a base
            
        public method enable takes boolean restart returns nothing
            enables spawn (makes it produce)
            
        public method disable takes nothing returns nothing
            disables spawn (stops making it produce)
            
        public method remove takes nothing returns nothing
            removes the spawn from the base it's attached to
        
        public method add takes Base b returns nothing
            adds the spawn to base b
            
        public method startMimic takes nothing returns integer
            puts spawn into mimic mode. Once in mimic mode, all
            changes to a spawn are not permanent.
            
        public method mimic takes integer s returns integer
            mimics another spawn entirely and puts spawn into mimic mode.
            s refers to the spawn to be mimic'd.
            
        public method mimicSpawnTime takes integer s returns integer
            mimics time of another spawn and puts spawn into
            mimic mode. s refers to other spawn.
            
        public method mimicSpawnType takes integer s returns integer
            mimics type of another spawn and puts spawn into
            mimic mode. s refers to other spawn.
            
        public method mimicSpawnCount takes integer s returns integer
            mimics count of another spawn and puts spawn into
            mimic mode. s refers to other spawn.
            
        public method mimicSpawnHandle takes integer s returns integer
            mimics handle of another spawn and puts spawn into
            mimic mode. s refers to other spawn.
            
        public method mimicMethodType takes integer s returns integer
            mimics method type of another spawn and puts spawn into
            mimic mode. s refers to other spawn.
            
        public method stopMimicSpawnTime takes nothing returns nothing
            stops mimicing time but does not take spawn out of
            mimic mode.
            
        public method stopMimicSpawnType takes nothing returns nothing
            stops mimic type but does not take spawn out of
            mimic mode.
            
        public method stopMimicSpawnCount takes nothing returns nothing
            stops mimicing count but does not take spawn out of
            mimic mode.
            
        public method stopMimicSpawnHandle takes nothing returns nothing
            stops mimicing handle but does not take spawn out of
            mimic mode.
            
        public method stopMimicMethodType takes nothing returns nothing
            stops mimicing method type but does not take spawn out of
            mimic mode.
            
        public method stopMimic takes nothing returns integer
            stops all mimicing and takes spawn out of mimic mode.
        
        public method revert takes nothing returns nothing
            sends spawn back to its previous base owner
            
        public method revertTo takes integer steps returns nothing
            sends spawn back an amount of steps.
        
        public method original takes nothing returns nothing
            sends spawn to original base owner.
            
        public method clone takes integer b returns integer
            clones and adds spawn to a base. b refers to the
            base to get the spawn.
            
        public method transfer takes integer b returns nothing
            removes spawn from its current base and sends it to
            another base. b refers to the base to recieve the spawn.
------------------------------------------------------------------
*/

 

[aznricepuff]

Mimicing is where one thing mimics another thing.... what's there to understand?

Why would I want to do that instead of just using the thing I'm mimicing? And when I want to go back, I just go back to the thing I was using before.

I might have some other things to say but I gotta go now.

 

[Nestharus]

Er... because you're already using the thing being mimic'd?? lol

Handle1 is owned by Player 2
Handle2 is owned by Player 0

Handle2 is some sucky dude with 0 power or w/e but a special mimic ability
Handle1 is an uber badass
Handle2 mimics Handle1 and the mimic lasts 2 minutes


???

And mimic is deep, so any bases and spawns would be mimic'd too, and all properties o-o. Plus, if you add any custom information you can inject into mimic and mimic that too : o.

When Handle2's mimic expires, then-
handle2.stopMimic()

Done ><.

And to mimic-
handle2.mimic(handle1)

lol...


Really what goes on is handle1.clone(owner of handle2)
handle2 is stored into handle2
handle2 is changed into the clone

And remember external handle pointing to internal? This ensures the id stays the same for data attachment.

The clone id inherits the initial handle id (saying that it's still the original thing), but it gets a unique mimic id, like which instance of a mimic (only as mimic mode turns on, meaning if u mimic 30x in a row, the mimic id stays the same, but if you do mimic then stopMimic then mimic, the mimic id is dif).

 

[aznricepuff]

Ok, so mimicing can actually do something to the game state other than just copying internal data. That makes more sense.

Ok, about those other things I was going to say:

Why don't you have any kind of type safety built into this? Why take in integer when you should be taking in Spawn (or w/e)? Unless you are actually taking in those ids you track internally. And if that's the case you should mention that in the API.

I don't like the naming of "Base". They're not bases. They're basically spawn data. So name it SpawnData...or something.

What's with Handle declaring a huge list of methods that may not ever be used. If I wrapped a special effect with something extending Handle, I don't want my wrapper to have anything except maybe get/set x/y (and even then maybe not, cuz maybe it's attached to a unit).

 

[Nestharus]

Like I said, that was 3.1 API ... lol

And also like I said, 4.0 can only do-
player
x
y
z
facing
typeId

And that is all : ). That is the minimum information Spawn requires to run, which is why that list was done. Originally, the idea was to let map makers just use the Handle for everything for completely 100% generic code, but that's no longer the case =P.

I don't want my wrapper to have anything except maybe get/set x/y (and even then maybe not, cuz maybe it's attached to a unit).

If you were wrapping a unit... you'd have setX getX etc... unless somehow your unit didn't have coords? All of the methods are wrappers too ><, lol.

Why don't you have any kind of type safety built into this? Why take in integer when you should be taking in Spawn (or w/e)? Unless you are actually taking in those ids you track internally. And if that's the case you should mention that in the API.

I don't have type safety because people aren't necessarily putting a spawn into a spawn slot. It could be an extension, in which case the type doesnt at all matter because they'd have to typecast it anyways =P.

er? people can access the attributes that store things like spawns and bases, but that feature is handled internally =). Pretty much everything in the entire system is public =P, meaning people can really just do w/e they want =).

I don't like the naming of "Base". They're not bases. They're basically spawn data. So name it SpawnData...or something.

I don't really like any of the names or the system name. And this is really more of a framework than a system ; o.

When I come up with a good name, I'll name them =). Base was originally contrived from the idea of-

A unit on the map
A base attached to a unit (like a spawnpoint)
Spawns attached to the base

3.1 was a 1:1:many relationship =P. The reason that there were bases was so that data could be moved more efficiently (a lot of people don't get that and tnk there should just be handles and bases).

-----------------------------------------------------------------------------------------------------------------
Also, the reason I'm posting up a lot of the development on Spawn 4.0 (name subject to change) is because I want people to get involved =).

What do people want to see in 4.0??

I'm already adding in-
modifier objects
onAdd
onRemove

And I'm changing around how the groups work with each other.

Also, I'm changing around how stuff works internally for better performance-
Each object attached to any other given object now has a count-
When an object is lent our or transferred, the amount is put in. If no amount is put in (0) (hopefully overloading some day), then the entire object is transferred (total count). A count of each attached object can be retrieved.

In this way, one spawn could be attached to multiple bases. The total spawn count would be the total spawn attachments (the count) * the spawnCount attribute.

Also, this allows objects to have unique counts of a spawn without a performance hit =).

New Thoughts:
A single base can already have different spawn origins (offsets or direct points). These spawn origins are put into various slots (a spawn put into index 0 spawns at one point, a spawn put into index 1 spawns at another point).

Rather than doing this, it might be more fruitful to spread out spawns (based on total spawnCount) over the origins, or to allow people to determine the specific origins themselves (the current way), or to determine an algorithm (like spawn algorithms), or any combo.

Dynamic Spawn Data-
Currently, spawn data is fully stored into attributes. Rather than this, they could be stored into either attributes, properties, or a combination. With them as properties, people can have full dynamic values (delegates pointing to interfaces like a lot of the other stuff). Yes, people can manipulate the attributes through injections and what not, but that's limited :\. In this way, people could either have more power and a little bit less performance if they need the power, or more performance if they don't need it =).

spawnCount could either be-
an integer
a method that returns an integer (might get various attributes from attachments and what not for a dynamic count)

Spawn Expiration-
A new Spawn expiration will be added. In this way, spawns might only work for an amount of time or might work until an event. They work off of a timer and or a trigger =). A Spawn Expiration of 0 means that the spawn doesn't expire. Also an age will be added and Spawn will require a game clock utility to track the game time. When a Spawn object is initially attached, it's assigned a birth for each instance (let's say you attach the same spawn 30x, each spawn gets a unique birth). When the expiration time is equal to gameTime - birth, the spawn is automatically detached.

Garbage Collector?
Should I put a garbage collector into this? It would be a performance hit : \, but there is a lot of memory and people wouldn't have to worry about cleaning up everything =P. Imagine 100s of units all with bases or w/e dying and being created o-o. You'd have to clean up the data for all of them ; O.

Auto Handle Creation-
Handles will gain a new method called autoCreate or something like that =P. They'll also get a trigger with autoCreate added to it = ). In essence, they can add new events to the trigger so that autoCreate runs. It should be used to auto put units or w/e into Spawn if the user desires. As autoCreate is a method, any boolean expressions can be used for filtering (maybe only units of a type, heroes, or items of a type, or w/e else, this way you don't waste data).

Possible Point Groups on Bases?
I'm still trying to figure out a fantastic way to do spawn point allocation (like where a spawn pops up on the map). The current ideas I have for it (algorithm, slots, spreading) are ok, but the question on spreading is how would it work o-o. Spawns don't necessarily know where they are spawning in relation to the base (I mean, they can determine that, or offset from the base's already setup data, but yea =P).

Also, complicated spawn structures based on the algorithm would need work too : \. If a spawn is spread out but works on a special algorithm, then everything could be screwed up. I suppose spawns could have a boolean as to whether they are allocated or not. Well, maybe I could do this-
point distribution patterns
3, 1, 5
3 spawns, then 1 spawn, then 5 spawns

That means if you had 3 points and 9 spawns-
Point 1: 3 spawns
Point 2: 1 spawn
Point 3: 5 spawns

If you had 10 spawns-
Point 1: 4 spawns (3+1 leftover)
Point 2: 1 Spawn
Point 3: 5 spawns

If you had 6 points and 9 spawns-
Point 1: 3 spawns
Point 2: 1 spawn
Point 3: 5 Spawns //will go as far as it can

Then you could have a minimum spawn count per point, like let's say if it were 2 (if it's greater than the smallest defined spawn distribution in a pattern, then the distribution wins, like if you said minimum was 2 and used example from above, it'd turn into 1 because 3, 1, 5's smallest number is 1) then it would first scatter spawns to various points to ensure everything was 2 =P. I mean, this obviously needs some work, but I'm sure it'll work out =).

Base Interiors-
This is something I've been wanting to do for awhile, and it'd require me to make something called Virtual Grids. In short, bases could have interiors that are linked up in a virtual cell fashion (meaning like a custom graph defined in jass laid over the wc3 graph).

For example, the most simple graph would be a square with 128x128 cells. 1, 1 would be 0, 0, 128, 128. 1, 2 would be 0, 128, 128, 256.

Well, these virtual grids could be defined and then when you hit the limit on a grid (minX, minY, minZ, maxX, maxY, maxZ) or a special cell (enter), then you are transported to the corresponding cell (data attachment on specific cell or limitation to another cell and transported to a coordinate in that cell based on offsets, like (maxX-minX)/2, (maxY-minY)/2, minY would be the floor of the center of the cell =).

Now, base interiors def still need work, but I really want to get them into Spawn 4.0. Also, the virtual grids would include dynamic grid allocation and instance creation. It'd hopefully be using a z offset to create things high up in the air, this way it doesn't interfere with the map. It'd also do layering to increase the instance limit. This would also increase maximum world size (instead of 480x480x0, it could be 480x480x500 (500/layerHeight layers, or layers world size. If layers were 5,
it'd be like 5 worlds =P))
-----------------------------------------------------------------------------------------------------------------
Tell me what other features you guys wanted to be added in Spawn. They need to be features that define Spawn, not features that Spawn defines. For example, if you asked for a spell effect that did poison or something like that, that'd be a spawn object : |...

If you asked for something like auto garbage collection in Spawn, or uhm... Linked bases using an extension of Base Interiors, then I'd probably be like, hey, sounds good ^_^. Actually, linked bases does sound good O_O.

If you say something like putting in levels of mimic and only mimicing if the level of the handle is <= the lever of the mimic, then that'd be something of a spell or injection or w/e, not something for Spawn to do = P.

Also, Base Interiors will likely be a module for Spawn as it can be split up. In fact, I'll try to modularize as much of Spawn as I possibly can o-o.

If you are interested in actually developing for Spawn, working on memory, efficiency, and so on, then go to the first post and read up on ERDs and the UML diagrams =P. I put up some great links : D.

If you got comments, then yea reply ^_^.

If anyone wants to do beta testing for Spawn (a special 4.0 private pre-release), then just PM me and I'll add you to a list : D.

There are going to be 2 other projects that are major works like Spawn that I'll be doing as well: Particle Motions and Virtual Grids. If you'd like to help out with those, you can PM me too =P. Particle Motions would be sorta like vex's xe but a lot more generic, able to do more stuff, and hopefully as efficient as possible =). My algorithm for homing projectiles was really good, so said all the people who tried it out =).

So yea >: D, get involved with this awesome project guys!! Oh yea... and we can port this over to SC2 when it comes out too : o. The memory and design is the part that takes up all the time =P. Moving code over is really easy =). Then again, might need a vGalaxy o-o.

I'm also working on the UML Diagrams, or trying to =o.

 

[azlier]

Graveyarded because there doesn't appear to be any actual Jass code anywhere.

Besides, you're already working on a rewrite.