Resources That Have Yet To Be Coded

[Nestharus]

If you find yourself at a loss for what to code or want to contribute to the community, then try your hand at coding one of these highly useful resources that has yet to be coded. Furthermore, there are plenty of current libraries that deserve updates (not listed).

Designs and specifications are provided.

Resources that have yet to be coded

Item Indexer ______________________________ No periodic loop Design NA Periodic Effect Output Given a set of effects, output the summation of these effects in one timer to prevent texttag spamming Design Every unit has n output variables: one for each property (health, mana, etc). The specific properties should be easy to iterate over as well as access. Given a buff that provides a unit with 3 health every second, then every second, that buff would add 3 to the health property output for that unit. On a separate timer for that unit, output the properties in one texttag (color coded, new lines, +/-, color code depending on both type and positive/negative) and then clear the properties. Expand upon http://www.hiveworkshop.com/forums/submissions-414/system-unit-attack-213779/ Allow users to change a unit's attack range (both min and max) and attack rate without spamming mass triggers like what is done in UnitAttack. Support default Warcraft 3 attack behavior. Data Structures http://en.wikipedia.org/wiki/List_of_data_structures#Data_types (whatever isn't in collections index that's useful) Get Closest Tile Type (water, blight, etc) Using either a quad tree or an octal tree, find the closest point with a given type to a point. Design Iterate over the map in 64x64 squares. For every square that has type, add that square to type tree. From here, given a point, find the nearest square to that point. Afterwards, find the nearest point within the square to that point. Keep in mind that water squares may be malformed. Floating Platform Create a floating platform given a unit that will fly at a constant over terrain (no going up/down) and keep all units on that platform moving with it. Furthermore, allow units to move between platforms, account for platform overlap, and account for z-height. Furthermore, allow units to fall off of platforms or force them to stay on the platform (can't walk off of it unless near another platform or terrain of similar height) (don't forget to only apply this to ground units). Buff Handling When applying buffs to a unit, the buff may already exist. Handle such collisions (overwrite if lower, stack, etc) and provide a list of buffs of type for a given unit, allowing external resources to iterate over these buffs in whatever way they'd like (for periodic, removal, checks, etc). Effect Using Lua (yes, wait until Lua is fixed), allow users to create effects like hex so that resources may apply whatever effect they want to a given unit (hex, sleep, etc). SetUnitType Using Lua (yes, wait until Lua is fixed), allow users to set a unit's type Vector Fields Provide a package of common vector fields to problems that are normally solved with trigonometry, such as rotation around a point. Matrix Operations Support creation of matrices size n,m and operations for them (addition, cross, dot, unit vector, etc) (only sensible ones) Polygon Support creation of polygons with n vertices and support checking if two polygons intersect and where, the area of an intersection between two polygons, and checking if a point is within a polygon. Polygons may be 3D. Library for Intersections with Common Shapes Support intersections of shapes given positions and rotations (do they intersect, where, and area of intersection). These shapes do not only include polygons, but ellipsoids, circles, cones, and so forth. Accept defined Polygons from Polygon library as well. Be sure to allow definitions of these shapes (ellipse for example) by things such as width, height, rotation, and phi or by focal points. Library for Intersections with Motion Given a velocity [x,y,z] and acceleration [a,b,c] for a shape and then another velocity/acceleration for another shape, as well as locations, rotations, etc for both shapes, determine whether they intersect in an interval over a period of time, what time they intersect/where, what time they stopped intersecting/where, how much the intersected, how long they intersected, and the average area of intersection with respect to time. Coordinate Transformation Support creating a basis in R^3 given a theta, phi, and linear transformation and support mapping coordinates from one basis to another, accounting for the change in theta (if basis one is rotated 30 degrees and basis two is 60 degrees, only rotate by an additional 30 degrees). Custom Unit Formation Support creating custom unit formations of n size with various position properties (like where a commander should go, siege units, and so forth) and allow them to be ordered about while maintaining the formation as much as possible. Unit Clustering Given properties such as target group count, minimum group count, maximum group count, minimum group size, maximum group size, target group size, maximum radius, minimum radius, target radius, maximum density, minimum density, target density, equal distribution, minimal distribution, and maximal distribution across an area for units of type(s) owned by player(s), cluster them into appropriate groups as efficiently as possible. Collection Element Lending For a list, allow that list to lend nodes out to other lists, and those lists to lend those same nodes out to other lists, and so forth. If a list is destroyed, then all borrowed nodes are returned to the last owner of those nodes (if last owner destroyed, it goes back more, etc) and all lent nodes are destroyed along with the list (lent nodes that belong to the list). Furthermore, if a list is destroyed, all lent nodes that were borrowed from another list go back to that other list. Allow a list to retrieve lent out nodes to n (how far to go out). Allow any given node to revert back n steps (original owner, or back to the last owner). Allow a list to take permanent ownership of any given node (cut off all ties to previous owners, making that list the new original owner). Allow a list to retrieve some node, or revert some lent out node. This can be useful for temporary buff stealing, spawn stealing, and so forth. Morale System Using a provided equation so that unit influence over morale can be calculated, determine a unit's morale where morale is based on allied/enemy forces and influence of one unit to another unit is applied logarithmically with respect to distance. Pass morale to a user function. The brute force approach would be to take a unit A, and then iterate over every other unit on the map and calculate their influence over that unit A, which would result in n(n+1)/2 iterations, where n is the number of units. With clustering, this can be optimized as only local units will effect each other (two units from two different forces will have little effect, but those forces may effect each other as a whole, thus simplifying the algorithm). Taking squads, and so forth all the way up to the grand force, a high-powered morale system can be written. Also account for force factors, like a broken formation, general weariness, and the routing of an allied force. Command System Assuming that a player's screen is locked to 1 unit and that the player may only command that one unit, allow players to issue orders to other nearby units through that unit. Should also be able to issue long distance orders by having units carry those order to other units. Furthermore, should be able to get battle information from far away battles from those same messengers. Battle Region System Determine whether or not a force is connected to the a main camp given a set of control points and how they are connected, one of these points being the main camp. First, determine which area the force is in, and then next, determine if that area is somehow connected to the main camp (can go through either neutral or ally control points). A force's position is 's center with relation to density, that is the average of the sum of all unit positions that are a part of that force, with extra weight given to more influential units like commanders. Autocast Wc3 AI to make player units automatically use spells, similar to how autoattack works. A* Given a tree

 

[PurgeandFire]

Cool ideas.

 

[mckill2009]

Wc3 AI to make player units automatically use spells, similar to how autoattack works.

Ummm, I think no need to code this coz there are many spells that can be casted by AI automatically...not all though...

@SetUnitType, Floating Platform
Interesting...

 

[Luorax]

@ItemIndexer

As far as I know this does not use any periodic checks or anything similar. It just requires you to replace your CreateItem calls with a custom one (kinda like how Damage works). It's a pretty good library, actually.

 

[Nestharus]

You shouldn't need to replace CreateItem with a CreateItemEx, or that will become incompatible with a lot of things. A general resource like that should plugin to the map w/o breaking everything .

 

[Luorax]

Well, if you write your libraries on your own, then you should be fine. It definitely screws up things for those that use a lot of public stuff though.

But without a peridoc loop or a custom create function, I'm not sure if it's even possible to do it (or at least I can't think of another solution). Without hooks, that is, but that's possibly the worst solution. Well, actually not that bad, unless you spam items like a madman.

 

[Almia]

@Nestharus
Just rewrite your Platform lib, and I will be happy

for the Effect, http://www.thehelper.net/threads/status.121686/
Though,this must be rewritten for a much better lib.

Also, for the Polygon, have you tried that NhoekMap in the Wc3c? It has a polygon like regions.

 

[Ruke]

Item Indexer
______________________________
No periodic loop

Why not?, are you playing w3 in a calculator?

One thing that could help, would be a test library (like phpunit).

 

[Magtheridon96]

The periodic timer wouldn't be accurate. You'd need something that instantly catches items as they appear on the map. This may require a lot of h4x0ring :|
Are there any abilities that fire or change somehow when an item is placed?

You'd need to find something as smart as the Undefend trick, but for items.

 

[Ruke]

The periodic timer wouldn't be accurate. You'd need something that instantly catches items as they appear on the map. This may require a lot of h4x0ring :|
Are there any abilities that fire or change somehow when an item is placed?

You'd need to find something as smart as the Undefend trick, but for items.

@ItemIndexer

As far as I know this does not use any periodic checks or anything similar. It just requires you to replace your CreateItem calls with a custom one (kinda like how Damage works). It's a pretty good library, actually.

edit:

You shouldn't need to replace CreateItem with a CreateItemEx, or that will become incompatible with a lot of things. A general resource like that should plugin to the map w/o breaking everything .

cjass or if don't wanna use it, just change the code.

 

[Almia]

We no want hooks.
we can't replace them. If someone puts an item using the Terrain Editor, then you are doomed.

 

[Ruke]

We no want hooks.
we can't replace them. If someone puts an item using the Terrain Editor, then you are doomed.

just dont put items using the terrain editor, why are you guys drowning in a glass of water?

but, if you want to allow them, use cjass or hook, your map will not die because of it.

 

[Almia]

Read my post, the one with the line in it.
Also, in the site you posted, it seems that Hooked functions are executed first.

 

[Ruke]

Read my post, the one with the line in it.

your map will not die because of it.

Also, in the site you posted, it seems that Hooked functions are executed first.

a timer with timeout = 0 should solve it.

 

[Almia]

Slow

 

[Ruke]

Slow

too much temptation, can't resist...

oh wth:

now seriously, keep less time optimizing and more creating awesome stuffs, unless that the resource really needs it.

 

[Magtheridon96]

We are all perfectly capable of making an Item Indexer for our maps, it is incredibly trivial. We are proposing the creation of one that satisfies the following criteria:

- You must be able to CnP the code into your map, possibly do some Object Editor work if that's needed, and it should simply work. You shouldn't be forced to modify any of your item creation code. This is the best way to have the system. You want a jimmy-proof system.
- No hooks. No, nope, no, not gonna happen, no, no, no, no, No! Just... No. Kthnx.
- No periodic loops. This can never be accurate no matter how low your timeout is because even a 0-second timer executes after the 'thread' finishes.
- No cJASS. It breaks vJASS resources easily.

It's not about optimization at all.

Hooks
The problem here is that hooks are global. They inject code everywhere, even in places you may not want them to. There are certain systems like the Bonus Damage system on this site and probably many others that create items as dummies for the sake of performing some unrelated operation or task. By using hooks, you will be doing 2 things:
1) You are tampering with the system by running code while it's performing an operation, and since you have global state in the whole map, you actually have the potential to break this system. These dummy items in that system are only an implementation detail. Everything on the outside does not know about the implementation details of the system. If an onIndex function runs when an item is indexed and you call a function from there inside this system which happens to require the creation of items for the performance of a task, you're fucked, because you have to devise a new design for either the item indexer or your system. Having a perfect item indexer for everyone to simply integrate and have working sounds more tempting than asking people to implement a system that they have to work around a lot.
2) You are exposing these dummy items everywhere. It will become impossible to have an item hidden from the Item Indexer. Unit Indexer does not have this problem. An Item Indexer using hooks will have it.

Periodic Loop
This is a terrible solution because it will not assign indexes to items immediately. You should be able to create an item and use its index directly. You can do this with a Unit Indexer. The semantics of an Item Indexer should match those of a Unit Indexer. The implementation details must be hidden and they must not have any affects on the behavior of your code.

 

[Nestharus]

Essentially, an item indexer that's as good as a unit indexer ;D

 

[Ceday]

If you make a item indexer which satisfies that criterias, give me your house adress I will send you a gift.

 

[Ruke]

1) You are tampering with the system by running code while it's performing an operation, and since you have global state in the whole map, you actually have the potential to break this system. These dummy items in that system are only an implementation detail. Everything on the outside does not know about the implementation details of the system. If an onIndex function runs when an item is indexed and you call a function from there inside this system which happens to require the creation of items for the performance of a task, you're fucked, because you have to devise a new design for either the item indexer or your system. Having a perfect item indexer for everyone to simply integrate and have working sounds more tempting than asking people to implement a system that they have to work around a lot.

its just an item indexer... don't be so exaggerated.

2) You are exposing these dummy items everywhere. It will become impossible to have an item hidden from the Item Indexer. Unit Indexer does not have this problem. An Item Indexer using hooks will have it.

is this a problem?, if it is, then just create an DontLookThatItem function...

Periodic Loop
This is a terrible solution because it will not assign indexes to items immediately. You should be able to create an item and use its index directly. You can do this with a Unit Indexer. The semantics of an Item Indexer should match those of a Unit Indexer. The implementation details must be hidden and they must not have any affects on the behavior of your code.

do we need so much accuracy?, why?

isn't this kinda the same situation of a timer library?, i mean, you don't want to use hooks/cjass/whatever, but you have this revolutionary code that will save your map and make some good coffee, solutions?, just change the code.

the one who really needs it, will do it (how many resource could you have on your map that you can't change a little bit of code ¬¬).

or, you can be even more crazy (?) and says that if your resource uses item manipulation you have to use X library to do it (not native ones) or at least post a version using it.

or, you can spend time looking for a solution like you are saying and less creating other stuffs, come on, it's just an item indexer guys!

 

[PurgeandFire]

Make it like PUI, problem solved (for those unfamiliar with PUI, you index when GetItemIndex() is called).

Really, unless someone discovers a new method to detect when an item is created or removed from the map, that godly item indexer system will never be created. The best implementation (IMO) with the least issues would be a PUI-like indexer, ditching index and deindex events. After all, it serves the main purpose--indexed items.

Perhaps first make the PUI-like item indexer. Then afterward, make an "item enter map" event using magic and fairy dust. Then you can incorporate it into the item indexer afterward (seamlessly too, since you would only be adding events--the API would stay the same).

 

[Magtheridon96]

do we need so much accuracy?, why?

local item i = CreateItem(...)

local integer id = GetItemIndex(i)

If something as simple as this breaks, the system is terrible.
Yes, you need accuracy.

is this a problem?, if it is, then just create an DontLookThatItem function...

That breaks the first criterion. I was gonna point this out so you didn't have to suggest such a function, but I thought I made it clear already with the first criterion ;|

Make it like PUI, problem solved (for those unfamiliar with PUI, you index when GetItemIndex() is called).

Really, unless someone discovers a new method to detect when an item is created or removed from the map, that godly item indexer system will never be created. The best implementation (IMO) with the least issues would be a PUI-like indexer, ditching index and deindex events. After all, it serves the main purpose--indexed items.

Perhaps first make the PUI-like item indexer. Then afterward, make an "item enter map" event using magic and fairy dust. Then you can incorporate it into the item indexer afterward (seamlessly too, since you would only be adding events--the API would stay the same).

Yes, a PUI-like system sounds wonderful. Make one, I can't think of a use-case where the semantics would be unwanted.

edit
Or not. You can't handle onDeindex events correctly, so it'd be useless for combat systems and shit. You'd need something with accurate onIndex and onDeindex.

 

[PurgeandFire]

Deindex has to be handled via periodic recycler (until someone finds out a way to detect removal without hooks, if there is a method out there). onIndex is kind of a hassle, but could be implemented as an extension.

As for it being useless--not entirely sure I agree. When do you need to perform something right when an item is removed from the map? I'd argue that items are only "useful" when a unit has it, so you only need to worry for when a unit loses an item. You can just detect drop events for most cases (unless RemoveItem() doesn't fire a drop event if the unit has it, in which case I agree that there could be problems...).

But yeah, I'll look into it a little more. Not saying that I'm reserving the idea though, if anyone else wants to go and make the indexer then by all means, go for it pls.

 

[Xonok]

So unit indexers are instant? Never noticed that when making spells.
Eventually I fixed it with a VERY easy custom function.
I copied the usual index function and made a version that can be called and returns the index. Then I made it so that the indexer hates units that are already indexed, to prevent double-indexing.

You could do the same with items and thus, you have instant indexing.

 

[Magtheridon96]

That's what PUI-like is, and it wouldn't out very well because you'd want instant deindexing. I think I found a way to make an Item Indexer that can deindex units instantly, but it'll involve some h4x and messing with memory that doesn't belong to us. Basically, it's fucking with runtime inheritance and vtables /o/

 

[Xonok]

That's what PUI-like is, and it wouldn't out very well because you'd want instant deindexing. I think I found a way to make an Item Indexer that can deindex units instantly, but it'll involve some h4x and messing with memory that doesn't belong to us. Basically, it's fucking with runtime inheritance and vtables /o/

Make a custom function for GetUnitValue, that also checks if the item is still existant. Voila, you effectively have instant deindexing for all practical purposes.
(If function returns 0, then unit isn't indexed for whatever reason)

 

[looking_for_help]

Can't this widgetevent be used to achieve instant deindexing? At least the description suggests this (I know nothing about widgetevents though).

 

[Magtheridon96]

Make a custom function for GetUnitValue, that also checks if the item is still existant. Voila, you effectively have instant deindexing for all practical purposes.

This is for an event, an instant event. Manual calls are not what we want to do here. We want an ItemIndexer with the exact same semantics as the Unit Indexer.

Can't this widgetevent be used to achieve instant deindexing? At least the description suggests this (I know nothing about widgetevents though).

It works for everything except selling (which is handled with the sell event of course) and a RemoveItem call, so yeah, that event would probably be used in an Item Indexer.

edit
Actually, Doomlord is claiming that it does work for RemoveItem after he tested it. Well. Wow.
Okay, we have deindexing down as we've handled these cases:

- RemoveItem
- Sell Item
- Kill Item

Now how about onIndex? These are the cases:

- Buy Item
- CreateItem
- Drop Item after killing creeps with Item Drop tables

The first is trivial to handle. The third can be handled via an Enum call after any unit with a drop table dies, but that isn't an efficient and reliable solution. I'd leave this as a last resort and attempt to find a better solution. As for the second case, I'm not so sure. I'll see what I can hack together later to see how typecasting between items and units can help in any way. You never know ^.^

 

[looking_for_help]

Ok cool, so it does work? Or is there a case remaining where it doesn't?

 

[Doomlord]

The test map to back up my claim =D

Did I mention that this also handles tomes and charged items? They are included in the test map btw.

globals
    trigger t = CreateTrigger()
endglobals

module OnInit
    static method onInit takes nothing returns nothing
        call init()
    endmethod
endmodule

struct Test extends array

    private static method onEsc takes nothing returns nothing
        call RemoveItem(gg_item_ratf_0010)
    endmethod

    private static method callBack takes nothing returns boolean
        call BJDebugMsg("Deindexed")
        return false
    endmethod
    
    private static method addItem takes nothing returns nothing
        call TriggerRegisterDeathEvent(t, GetEnumItem())
    endmethod

    static method init takes nothing returns nothing
        local trigger t1 = CreateTrigger()
        
        call TriggerRegisterPlayerEvent(t1, Player(0), EVENT_PLAYER_END_CINEMATIC)
        call TriggerAddAction(t1, function thistype.onEsc)
        
        call EnumItemsInRect(bj_mapInitialPlayableArea, null, function thistype.addItem)
        call TriggerAddCondition(t, function thistype.callBack)
        set t1 = null
    endmethod
    
    implement OnInit
endstruct

edit

Just to be clear, this is by pure chance that I discovered this while coding my CSS system =)

edit

Okay so are we missing any case? I will just post a recap of the handled circumstances here~

• Remove Item.
• Kill Item.
• Sell Item.
• Tome Usage.
• Consumable Items.
• Charged Items.

 

[Magtheridon96]

I found an exploit we can use to make an Item Enter Region event for specific items.
We can't do this for all items in general with my method though :|

I'll be testing my hypothesis as soon as I get Warcraft III and NewGen up and running on my new machine~

 

[looking_for_help]

Ok, so the only missing case is CreateItem (if we assume that an event for CreateItem would also solve Item Drop tables), is that correct?

 

[Ruke]

If something as simple as this breaks, the system is terrible.
Yes, you need accuracy.

already cover by purge's solution.

The first is trivial to handle. The third can be handled via an Enum call after any unit with a drop table dies, but that isn't an efficient and reliable solution. I'd leave this as a last resort and attempt to find a better solution. As for the second case, I'm not so sure. I'll see what I can hack together later to see how typecasting between items and units can help in any way. You never know ^.^

It's not about optimization at all.

@doom, what an ingenius solution , but, will that leak when items get destroyed (event leak)?

 

[Doomlord]

@doom, what an ingenius solution , but, will that leak when items get destroyed (event leak)?

Yeah thanks. I don't really deserve the credit though, it is just pure luck =))

And about the event leak, please forgive me for not knowing how to respond to that. I just started learning vJASS recently and up until now I didn't really immerse myself in the advanced mechanics of warcraft 3. If you would be kind enough to give me some insights, that would be really nice

edit

Right so after looking at my old system again, Geries (the guy who coded the register item death thing for me) implemented a recycler for the event. I am not really sure if this is the event leak we are talking about though

 

[Ruke]

Yeah thanks. I don't really deserve the credit though, it is just pure luck =))

And about the event leak, please forgive me for not knowing how to respond to that. I just started learning vJASS recently and up until now I didn't really immerse myself in the advanced mechanics of warcraft 3. If you would be kind enough to give me some insights, that would be really nice

lets say that you have a trigger that listen for damages on X unit, but that unit is removed, what happens then?, the trigger continues listening, even when the unit isn't there anymore, which ends up in an event leak.

edit

Right so after looking at my old system again, Geries (the guy who coded the register item death thing for me) implemented a recycler for the event. I am not really sure if this is the event leak we are talking about though

yes it is.
well, another future usage for the event cleaner maded by nes c:

 

[Doomlord]

lets say that you have a trigger that listen for damages on X unit, but that unit is removed, what happens then?, the trigger continues listening, even when the unit isn't there anymore, which ends up in an event leak.

Right. That. Yes of course an event recycler can always be implemented.

Can you show me how to test whether it leaks or not?

 

[Ruke]

Can you show me how to test whether it leaks or not?

someone correct me if i'm wrong, but it should continue using memory (it will not decrease) even when you destroy the item.

 

[Doomlord]

someone correct me if i'm wrong, but it should continue using memory (it will not decrease) even when you destroy the item.

How do you do that? Is there a way to view the amount of memory consumed by Wc3? A single event or two is perhaps not going to make any noticable change if you are using Windows Task Manager

 

[looking_for_help]

Easiest way to be sure: Create new items with a 0.01 timer, add the event to them and remove the item. Then watch your task manager if memory usage goes up. If it leaks (which is what I expect) then the memory usage should increase quite fast.

 

[Magtheridon96]

@Ruke

What's your point?

When I said it wasn't about optimization, I was talking about avoiding hooks.
I already stated what problems both periodic timers and hooks have, must I quote myself and make this post bigger than it should be? No. Refer to page 2.

Enum isn't even that reliable -_-
I was pointing out that the solution fails because it's both unreliable and inefficient. Lose-Lose.

 

[looking_for_help]

Ok tested, it leaks events. This scripts slowly fills up memory:

Leak

globals
    trigger t = CreateTrigger()
endglobals

module OnInit
    static method onInit takes nothing returns nothing
        call init()
    endmethod
endmodule

struct Test extends array

    private static method timer_callback takes nothing returns nothing
        local item it
    
        set it = CreateItem('ratf', 0.0, 0.0)
        call TriggerRegisterDeathEvent(t, it)
        call RemoveItem(it)
        set it = null
    endmethod
    


    static method init takes nothing returns nothing
        local trigger t1 = CreateTrigger()
        call TriggerRegisterTimerEvent(t1, 0.001, true)
        call TriggerAddAction(t1, function thistype.timer_callback)
        
    
        set t1 = null
    endmethod
    
    implement OnInit
endstruct

But as we have flawless onDeIndex it shouldn't be a problem to solve this.

 

[Doomlord]

Ok tested, it leaks events. This scripts slowly fills up memory:

Leak

globals
    trigger t = CreateTrigger()
endglobals

module OnInit
    static method onInit takes nothing returns nothing
        call init()
    endmethod
endmodule

struct Test extends array

    private static method timer_callback takes nothing returns nothing
        local item it
    
        set it = CreateItem('ratf', 0.0, 0.0)
        call TriggerRegisterDeathEvent(t, it)
        call RemoveItem(it)
        set it = null
    endmethod
    


    static method init takes nothing returns nothing
        local trigger t1 = CreateTrigger()
        call TriggerRegisterTimerEvent(t1, 0.001, true)
        call TriggerAddAction(t1, function thistype.timer_callback)
        
    
        set t1 = null
    endmethod
    
    implement OnInit
endstruct

But as we have flawless onDeIndex it shouldn't be a problem to solve this.

Nice. Thanks for testing lfh

Iirc, we have that event recycler thing right? Or trigger refresh. Not really sure =P

 

[Magtheridon96]

already cover by purge's solution.

Still doesn't give us onIndex. We're not going with Purge's solution alone.

 

[Nestharus]

Oh, and for future resources, keep in mind that we are working on a new standard 4.

This standard includes:

modular design
encapsulation
good variable naming practice
documentation
testing suites/unit testing
no extensions
no static plugins
standardized collections (except for special cases)
standardized error checking
standardized error output
standardized error behavior
standardized allocation (except for special cases)

Resources that are compliant and have passed error checking tests earn a green Pass. Future resources must earn a green Pass to be approved. Current resources that are not compliant but are bug free get a blue Works.

Also planning on a categorized resource page as the JASS section continues to grow =), so this means that in order to be approved, you need to also create a small thing for your resource to go on to the resource page (more details later).

This is just in case you wanna write something new. As the standards are being defined, they are being enforced ; p.

 

[Ruke]

testing suites/unit testing

promote tdd would be awesome c:
but first, a library to make easy unit testings.

 

[Almia]

OH shit!
Nice idea Purgey!

 

[Fingolfin]

I haven't really read this thread, but i would totally suggest an A*-based custom pathing system, like the PAS system we had some years ago which was broken when the return bug was removed.

Basically what you did was to add nodes using rects, and then specify which other nodes it was connected to (you could also give each a custom name, like "village", "castle" for easy reference). The idea was, that if you would order a unit to move from point A to B, it would find the closest node to A and the closest to B, and calculate a path between them (looking through the node chain), making the unit move by said path.

This was VERY useful for simulating npc civilians using the pavewalk and street crossings in a city, and would also be usefull in pretty much any situation where you override wc3s regular unit movement (for instance, i have systems that make ships move in smooth curves, accelerate/decelerate, etc).

Note that unlike most rts pathing system it did NOT take the entire grid into account, it was instead waypoint based, with the number of waypoints/nodes ranging between 10 and 100 in any given game. This means it was never very performance heavy. The pathing between the nodes was handled by the regular wc3 pathing system (the units were just ordered to issue a specified order towards the next node, like "attack" or "move").

 

[Nestharus]

That's a good idea, and that can be done too.

Just use a Graph or a Tree and then traverse along it using a Queue and a boolean array.

 

[Nestharus]

Let's scrap this, nobody cares. It's all self glorified crap >.>

people should just code w/e they wanna code

 

[Almia]

At last!!
Im free!!!