3D Object Collision and Jump System v0.7.0.0 Beta

This bundle is marked as approved. It works and satisfies the submission rules.

Description

Manual!


This system is created to allow you to create physics like a
3rd person shooter with a 3rd dimension to their physics system.

For example if you want want to make a bridge, without this system
you would only be able to go either under or over and not both.
With this you are able to do both at the same time while also falling
onto and off and also jump to and from them smoothly.

Check the Manual tab to find out what
you can do with this system.

Instructions on how to import the system are inside the test map

Basic test map controls:

Change log:

Known bugs:

Ideas:

Credits:


  1. Use the arrow keys to move
  2. Use the "Q" hotkey to jump
  3. Select other unit to change interface over to it
0.7.0.0 beta
  1. Documentation:
    - Listed out in the manual all the usable functions and variables
    in this system
    - Documented all triggers that are a part of this system
    - Updated the importing documentation a little
  2. Merged, optimized and organized a lot of code
  3. Removed some requirments:
    - ForAllDest
    - GetLocZ
    - CheckAngle
    - IsPlaying
    - InitArrowKey
    - AllowFlight
    Added some new ones:
    - PlayerManager
    - AutoFlight
    - GetTerrainZ
    - ArrowEvent
    - ArriwEvent_PlayerRegister
  4. Setting custimizability:
    - Created settings trigger that contains constant value customizability
    - Created functions and variables the can customize for unit unit types
    (Only works on newly/to be created units)
    - Can customize specific system unit settings at any time
    - Due to custimizability of unit settings, the static method no longer
    use the width and height variables
  5. Collision objects:
    - Added 2D Circle creation
    - Can recreate 3D Rectangles dimensions with other 3D Rectangle Id
    - Can now check if a unit is inside a 3D Rectangle
    - Created some technical functions for indexing collision objects
Check out the full log here

  1. Edge of object clipping occurs
  2. Setting a destructables health % to 0 will not remove the
    collision object attached to it
  3. Walking to colide with 3D objects in particular situations will cause the
    unit to stop insdead of moving along side of it
(Not tested)
  1. If you try and collide with a thin enough object, have a high enough move
    rate you or/and have a thin enough unit you might walk through the object
  2. Removing a 3D collision objects that is attached to
    an destructable before killing the detstructable first will cause bugs
  3. Some functions are not compleyely safe to run
(A possibility)
  1. Some objects may not register or get destroyed properly
    in certain situation
(Not debugable afaik)
  1. Walking off the edge of the map will make your units
    model disappear. ((Not tested.) Although it is possible
    to create collision objects outside the edge of the map)
  2. Creating collition objects with any patch of blizzard water
    will create glitching (must have no indication of blizzard water
    around objects with this system for this system to function)

  1. Unit Movement with mouse clicks (allow disabling of the Camera
    Arrow structs to be replaced by the normal camera and movement to
    be made by clicks)
  2. Use plains for collition (will help with unnesesary object clipping)
  3. Allow sliding along edges of objects to not stop movment with a
    thickness limit
  4. Make sliding on steep cliffs
  5. Allow usage of triangle like 3D object with z variance
  6. Allow a function call that can call once or multiple times when a unit
    enters a 3D objects area and can get the unit that entered
  7. Have a hack for WE that allows placment of 3D collition objects or
    atleast detect the Z value(or fly height like units) of destructables
  8. When destructables are moved that have objects attached to them move
    them with the destructable and viseversa
  • Nestharus for the Unit indexer and its requirments
  • Bribe for the base ArrowKeyEvent System
  • Creators of jass newgen pack and Wc3
  • DeathChef for the system itself


Pic no.1:

Pic no.2:

Pic no.3:

Pic no.4:

attachment.php
attachment.php
attachment.php
attachment.php





The content in this manual shows only the user friendly
functionality, meaning that this system can create, edit
and use more modifiable script that is provided in this
system

Future updates may provide more detail on extra content
control

Content in this system may be changed in future updates


Content;
Using static method

Unit
- Movement
- SystemUnit
- Camera
- Arrow
- Interface​
Object
- 3DRectangle
- 2DCircle​




Using static method

For any static method to be executed in your code a prefix of the struct name
it came from has to be declared before the static method name

Eg;
JASS:
        //for units
    local real x = SystemUnit.GetX(UnitA)
    call SystemUnit.Attach(UnitB, x, 60)
        
        
        //for 3D Rectangle objects
    call RectangleObject.Create(231, 313, 43, 143, 53, 152)
    call RectangleObject.RemoveInRectangleArea(321, 367, 456, 765)



For further information on how to use struct, check out the vJass manual
http://www.wc3c.net/vexorian/jasshelpermanual.html

Unit

The attached units will be able to collide and walk on the objects created for this system

Attached units will be given the potential ability to
. be given the ability to jump
. have the owning players vision locked to it
. be able to be ordered to walk by the arrow keys
. be able to be ordered to walk by right mouse click order (currently under construction)


Units that die automatically get detached
Once this unit is detached everything in this system for the unit will be removed with it

JASS:
struct Movement extends array

    Description
        /*
        Core periodic event for getting units attached to system,
        checking if any object is blocking their path and settings
        that units coordinates to appropriate position.
        */
        
    Methods
        
        static method Start takes nothing returns nothing
        
        static method Stop takes nothing returns nothing

JASS:
struct SystemUnit extends array
    
    Description
        /*
        Core of units attached to the system containing the variables
        of those units, the initializers for attaching them and attaching
        methods to them. Detaches any unit on death.
        */
        
    Fields
        
        static integer Count
        
        unit Unit
        integer UserData
        integer Index
        
        boolean Attached
        
        player User
        integer UserId
        
        real X
        real Y
        real Z
        real Facing
        real Height
        real Width
        
        
        real Distance
        real Angle
        
        
        real AirTime
        
        boolean CanJump
        
        
        real DropRate
        
        real InitialJumpRate
        
        real StopSpeed
        real WalkSpeed
        real WalkStraightSpeed
        real TurnSpeed
        
        integer AnimationIndexWalk
        integer AnimationIndexStand
        
        real AnimationSpeedWalkForward
        real AnimationSpeedWalkBackward
        real AnimationSpeedTurnOnSpot
        
        /
        
        static integer TypeIdCount
        
        hashtable TypeIdIndex
        
        real TypeIdDropRate
        
        real TypeIdInitialJumpRate
        
        real TypeIdStopSpeed
        real TypeIdWalkSpeed
        real TypeIdWalkStraightSpeed
        real TypeIdTurnSpeed
        
        integer TypeIdAnimationIndexWalk
        integer TypeIdAnimationIndexStand
        
        real TypeIdAnimationSpeedWalkForward
        real TypeIdAnimationSpeedWalkBackward
        real TypeIdAnimationSpeedTurnOnSpot
        
        
        
    Methods
        
        static method init takes unit u returns thistype
        
        static method deinit takes thistype this returns nothing
        
        
        /
        
        static method AttachAll          takes unit u                          returns nothing
        static method AttachAllInterface takes unit u, integer UnitInterfaceId returns nothing
        
        static method AttachUnit         takes unit u                          returns nothing
        static method AttachCamera       takes unit u                          returns nothing
        static method AttachInterface    takes unit u, integer UnitInterfaceId returns nothing
        static method AttachArrow        takes unit u                          returns nothing
        
        static method DetachUnit      takes unit u returns nothing
        static method DetachCamera    takes unit u returns nothing
        static method DetachInterface takes unit u returns nothing
        static method DetachArrow     takes unit u returns nothing
        
        /
        
        static method GetTypeIdHeight                     takes integer UnitTypeId returns real
        static method GetTypeIdWidth                      takes integer UnitTypeId returns real
        
        static method GetTypeIdDropRate                   takes integer UnitTypeId returns real
        
        static method GetTypeIdInitialJumpRate            takes integer UnitTypeId returns real
        
        static method GetTypeIdStopSpeed                  takes integer UnitTypeId returns real
        static method GetTypeIdWalkSpeed                  takes integer UnitTypeId returns real
        static method GetTypeIdWalkStraightSpeed          takes integer UnitTypeId returns real
        static method GetTypeIdTurnSpeed                  takes integer UnitTypeId returns real
        
        static method GetTypeIdAnimationIndexWalk         takes integer UnitTypeId returns integer
        static method GetTypeIdAnimationIndexStand        takes integer UnitTypeId returns integer
        
        static method GetTypeIdAnimationSpeedWalkForward  takes integer UnitTypeId returns real
        static method GetTypeIdAnimationSpeedWalkBackward takes integer UnitTypeId returns real
        static method GetTypeIdAnimationSpeedTurnOnSpot   takes integer UnitTypeId returns real
        
        
        static method SetTypeIdHeight                     takes integer UnitTypeId, real h     returns nothing
        static method SetTypeIdWidth                      takes integer UnitTypeId, real w     returns nothing
        
        static method SetTypeIdDropRate                   takes integer UnitTypeId, real dr    returns nothing
        
        static method SetTypeIdInitialJumpRate            takes integer UnitTypeId, real ijr   returns nothing
        
        static method SetTypeIdStopSpeed                  takes integer UnitTypeId, real ss    returns nothing
        static method SetTypeIdWalkSpeed                  takes integer UnitTypeId, real ws    returns nothing
        static method SetTypeIdWalkStraightSpeed          takes integer UnitTypeId, real wsp   returns nothing
        static method SetTypeIdTurnSpeed                  takes integer UnitTypeId, real h     returns nothing
        
        static method SetTypeIdAnimationIndexWalk         takes integer UnitTypeId, real aiw   returns nothing
        static method SetTypeIdAnimationIndexStand        takes integer UnitTypeId, real ais   returns nothing
        
        static method SetTypeIdAnimationSpeedWalkForward  takes integer UnitTypeId, real aswf  returns nothing
        static method SetTypeIdAnimationSpeedWalkBackward takes integer UnitTypeId, real aswb  returns nothing
        static method SetTypeIdAnimationSpeedTurnOnSpot   takes integer UnitTypeId, real aston returns nothing
        
        /
        
        static method GetX                          takes unit u returns real
        static method GetY                          takes unit u returns real
        static method GetZ                          takes unit u returns real
        static method GetFlyHeight                  takes unit u returns real
        static method GetFacing                     takes unit u returns real
        
        static method GetHeight                     takes unit u returns real
        static method GetWidth                      takes unit u returns real
        
        static method GetDropRate                   takes unit u returns real
        
        static method GetInitialJumpRate            takes unit u returns real
        
        static method GetStopSpeed                  takes unit u returns real
        static method GetWalkSpeed                  takes unit u returns real
        static method GetWalkStraightSpeed          takes unit u returns real
        static method GetTurnSpeed                  takes unit u returns real
        
        static method GetAnimationIndexWalk         takes unit u returns integer
        static method GetAnimationIndexStand        takes unit u returns integer
        
        static method GetAnimationSpeedWalkForward  takes unit u returns real
        static method GetAnimationSpeedWalkBackward takes unit u returns real
        static method GetAnimationSpeedTurnOnSpot   takes unit u returns real
        
        
        static method SetXYZFacing                  takes unit u, real x, real y, real z, real f returns nothing
        static method SetXYFlyHeightFacing          takes unit u, real x, real y, real z, real f returns nothing
        static method SetXYZ                        takes unit u, real x, real y, real z         returns nothing
        static method SetXYFlyHeight                takes unit u, real x, real y, real z         returns nothing
        static method SetXYFacing                   takes unit u, real x, real y, real f         returns nothing
        static method SetXY                         takes unit u, real x, real y                 returns nothing
        static method SetX                          takes unit u, real x                         returns nothing
        static method SetY                          takes unit u, real y                         returns nothing
        static method SetZ                          takes unit u, real z                         returns nothing
        static method SetFlyHeight                  takes unit u, real z                         returns nothing
        static method SetFacing                     takes unit u, real f                         returns nothing
        
        static method SetHeight                     takes unit u, real h                         returns nothing
        static method SetWidth                      takes unit u, real w                         returns nothing
        
        static method SetDropRate                   takes unit u, real dr                        returns nothing
        
        static method SetInitialJumpRate            takes unit u, real ijr                       returns nothing
        
        static method SetStopSpeed                  takes unit u, real ss                        returns nothing
        static method SetWalkSpeed                  takes unit u, real ws                        returns nothing
        static method SetWalkStraightSpeed          takes unit u, real wsp                       returns nothing
        static method SetTurnSpeed                  takes unit u, real h                         returns nothing
        
        static method SetAnimationIndexWalk         takes unit u, integer aiw                    returns nothing
        static method SetAnimationIndexStand        takes unit u, integer ais                    returns nothing
        
        static method SetAnimationSpeedWalkForward  takes unit u, real aswf                      returns nothing
        static method SetAnimationSpeedWalkBackward takes unit u, real aswb                      returns nothing
        static method SetAnimationSpeedTurnOnSpot   takes unit u, real aston                     returns nothing

JASS:
struct Camera extends array
    
    Description
        /*
        Attaches the owner of a units camera to the unit.
        
        Is a requirment for Arrow commands and Unit interface.
        */
        
    Fields
        
        static boolean LocalPlayerAttached = false
        static integer LocalAttachedIndex
        
        unit Unit
        
        
    Methods
        
        static method init takes SystemUnit this returns nothing
        
        static method deinit takes SystemUnit this returns nothing

JASS:
struct Arrow extends array
    
    Description
        /*
        Allows for Arrow key movement to the attached unit.
        
        Requires Camera unit attachment.
        */
        
    Fields
    
        boolean IsUp
        boolean IsDown
        boolean IsLeft
        boolean IsRight
        
        unit Unit
        integer Id
        
        
    Methods
        
        static method init takes SystemUnit Index returns nothing
        
        static method deinit takes SystemUnit Index returns nothing

JASS:
struct Interface extends array
    
    Description
        /*
        Disables right click mobility and removes the command abilities.
        
        Requires Camera unit attachment.
        */
        
    Fields
    
        unit Unit
        integer UserData
        integer Index
        
        boolean Attached
        
        
        
    Methods
        
        static method init takes thistype this, integer Id returns nothing
        
        static method deinit takes thistype this returns nothing
        static method deinit2 takes thistype this, thistype Count returns nothing


Object

For any unit attached to this system it will be able to collide and walk
on top of the objects created and initialized from the map script.

Note: The objects created in this system represent no art form, other
than collision (the actual objects themselves are invicible).

When any destructable gets destroyed the object that is attached to
it will be removed with it

JASS:
struct Rectangle3D extends array
    
    Description
        /*
        Collision check for reassigning units position outside of
        object if ever intercept with the objects coordinate limits
        */
        
    Fields
        
        real MinX
        real MaxX
        real MinY
        real MaxY
        real MinZ
        real MaxZ
        
        static hashtable Sector
        static hashtable SectorIndex
        static hashtable SectorUserData
        integer SectorCount
        integer SectorIndexCount
        
        integer Recycler
        static thistype RecyclerCount
        
        boolean Attached
        
        
        destructable Dest
        static hashtable DestIndex
        integer DestHandle
        
        boolean DestAttached
        
        
        static InterfaceGetObjectId forObject
        
        
    Methods
        
        static method Create takes real MinX, real MaxX, real MinY, real MaxY, real MinZ, real MaxZ returns integer
        static method Recreate takes real x, real y, thistype Object returns integer
        static method RecreateZ takes real x, real y, real z, thistype Object returns integer
        
        static method DoesExist takes thistype ObjectId returns boolean
        static method CreateIndex takes real MinX, real MaxX, real MinY, real MaxY returns integer
        static method Remove takes thistype ObjectIndex returns nothing
        
        
        static method AttachToDest takes destructable d, thistype ObjectIndex returns nothing
        
        static method CreateAttachedToDest takes destructable d, real MinX, real MaxX, real MinY, real MaxY, real MinZ, real MaxZ returns nothing
        static method CreateAttachedToDests takes integer DestId, real MinX, real MaxX, real MinY, real MaxY, real MinZ, real MaxZ returns nothing
        
        static method DetachDest takes thistype ObjectIndex returns nothing
        static method DetachFromDest takes destructable d returns nothing
        
        static method RegisterDestDeathEvent takes destructable d returns nothing
        static method DestroyDestDeathEvent takes destructable d returns nothing
        
        static method GetDestIndex takes destructable d returns integer
        static method GetAttachedDest takes thistype ObjectId returns destructable
        static method HasDestAttached takes thistype ObjectId returns boolean
        static method IsDestAttached takes destructable Dest returns boolean
        
        
        static method ForSectorsInCoordinates takes real MinX, real MaxX, real MinY, real MaxY, InterfaceGetObjectId temp_forObject returns nothing
        
        static method ForSectorsInCoordinatesExclusive takes real MinX, real MaxX, real MinY, real MaxY, InterfaceGetObjectIdWithUnit forObject, SystemUnit Unit returns nothing
        
        
        static method ForAllObjectsInRectangleObject takes RectangleObject ObjectId, InterfaceGetObjectId forObjectId returns nothing
        static method ForAllObjectsInRectangleArea takes real MinX, real MaxX, real MinY, real MaxY, InterfaceGetObjectId forObjectId returns nothing
        
        static method ForAllObjectsInRectangleAreaZ takes real MinX, real MaxX, real MinY, real MaxY, real MinZ, real MaxZ, InterfaceGetObjectId ObjectId returns nothing
        
        
        static method IsUnitInsideId takes RectangleObject Object, SystemUnit this returns boolean
        static method IsUnitInside takes RectangleObject Object, unit u returns boolean
        
        static method IsUnitInsideAnyId takes SystemUnit this returns boolean
        static method IsUnitInsideAny takes unit u returns boolean
        
        
        static method GetMinX takes thistype ObjectId returns real
        static method GetMaxX takes thistype ObjectId returns real
        static method GetMinY takes thistype ObjectId returns real
        static method GetMaxY takes thistype ObjectId returns real
        static method GetMinZ takes thistype ObjectId returns real
        static method GetMaxZ takes thistype ObjectId returns real
        
        static method GetX takes thistype ObjectId returns real
        static method GetY takes thistype ObjectId returns real
        static method GetZ takes thistype ObjectId returns real
        
        
        static method SetMinX takes thistype ObjectId, real minX returns nothing
        static method SetMaxX takes thistype ObjectId, real maxX returns nothing
        static method SetMinY takes thistype ObjectId, real minY returns nothing
        static method SetMaxY takes thistype ObjectId, real maxY returns nothing
        static method SetMinZ takes thistype ObjectId, real minZ returns nothing
        static method SetMaxZ takes thistype ObjectId, real maxZ returns nothing
        
        static method SetXYZ takes thistype ObjectId, real x, real y, real z returns nothing
        static method SetXY takes thistype ObjectId, real x, real y, real z returns nothing
        static method SetX takes thistype ObjectId, real x returns nothing
        static method SetY takes thistype ObjectId, real y returns nothing
        static method SetZ takes thistype ObjectId, real z returns nothing

JASS:
struct Circle2D extends array
    
    Description
        /*
        Collision check for reassigning units position outside of
        object if ever intercept with the objects coordinate limits
        */
        
    Modules
        
        Circle2D_CreateAll
        
        ObjectAddons
        
        
    Fields
        
        real x
        real y
        real z
        
        real Radius
        
        boolean HasTop
        boolean HasBottom
        
        
        static hashtable Sector
        static hashtable SectorIndex
        static hashtable SectorUserData
        integer SectorCount
        integer SectorIndexCount
        
        integer Recycler
        static thistype RecyclerCount
        
        boolean Attached
        
        
        destructable Dest
        static hashtable DestIndex
        integer DestHandle
        
        boolean DestAttached
        
        
        static InterfaceGetObjectId forObject
        
        
    Methods
        
        static method Create takes real x, real y, real z, real Radius, boolean HasTop, boolean HasBottom returns integer
        
        static method DoesExist takes thistype ObjectId returns boolean
        static method CreateIndex takes real MinX, real MaxX, real MinY, real MaxY returns integer
        static method Remove takes thistype ObjectIndex returns nothing
        
        
        static method AttachToDest takes destructable d, thistype ObjectIndex returns nothing
        
        static method CreateAttachedToDest takes destructable d, real x, real y, real z, real Radius, boolean HasTop, boolean HasBottom returns nothing
        static method CreateAttachedToDests takes integer DestId, real z, real Radius, boolean HasTop, boolean HasBottom returns nothing
        
        static method DetachDest takes thistype ObjectIndex returns nothing
        static method DetachFromDest takes destructable d returns nothing
        
        static method RegisterDestDeathEvent takes destructable d returns nothing
        static method DestroyDestDeathEvent takes destructable d returns nothing
        
        static method GetDestIndex takes destructable d returns integer
        static method GetAttachedDest takes thistype ObjectId returns destructable
        static method HasDestAttached takes thistype ObjectId returns boolean
        static method IsDestAttached takes destructable Dest returns boolean
        
        static method ForSectorsInCoordinates takes real MinX, real MaxX, real MinY, real MaxY, InterfaceGetObjectId temp_forObject returns nothing
        
        static method ForSectorsInCoordinatesExclusive takes real MinX, real MaxX, real MinY, real MaxY, InterfaceGetObjectIdWithUnit forObject, SystemUnit Unit returns nothing




Keywords:
3D, Object, Collision, Jump, System, DeathChef, Dashie, Physics, Maths, vJass
Contents

Object Collision and Jump System (Map)

Reviews
22:33, 14th Jun 2015 PurgeandFire: Review: http://www.hiveworkshop.com/forums/2695096-post28.html
Level 23
Joined
Mar 15, 2012
Messages
2,665
About time you released it, I think this system would benefit greatly with a cube-like terrain system. That way hills and water wouldn't be so malfunctioning.

So how many objects/units can this support? I am guessing around 50 if that, hope its higher.

Edit: It's possible to go under and over bridges without arrow key movement, just it's rather glitchy.
 
I Hope that people will enjoy and put this system to good use.
I've devoted a lot of time into it and has helped me a bunch to develop my coding skills.

Please report any bugs that aren't already on the list, tell me your opinion on the system with what you think could be improved/changed for better etc.
I'd probably like to hear from pretty much anyone.

Make sure to check out the known bugs if you find issues

Check out the ideas tab if your interested to see what ideas I have for any possible future versions
Also check out the Manual next to the main description tab for function list or check it out in the test map


___


About time you released it
Lol yeh it's kinda just been sitting in the lab for the last 1 1/2 months.
I actually haven't touched the code or anything else inside the test map since.

I think this system would benefit greatly with a cube-like terrain system. That way hills and water wouldn't be so malfunctioning.
It should technically be able to support any kind of map with consideration of bugs.

Also note known bug.
5. Creating collision objects with any patch of blizzard water
will create glitching (must have no indication of blizzard water
around objects with this system for this system to function)


So how many objects/units can this support? I am guessing around 50 if that, hope its higher.

If I remember right it supports one unit at a time.
If a player that already has a unit to control and that same player is given a new unit the new unit replaces it (I don't remember testing it though).

Objects are split and indexed into different sections (with a hashtable) so for each unit being checked each instance only the objects in the units sector are checked.

So theoretically if all objects are done by hand it should be how much data a hashtable can handle depending on different situations to.

Objects that are created over destructibles are limited to how many can be checked at once in 4 different square sectors of the map or otherwise limited by the OP limit (8,191) theoretically.

_

In simple:
  • One controlled unit at a time per player (MPI)
  • More objects than any normal map would ever need

Edit: It's possible to go under and over bridges without arrow key movement, just it's rather glitchy.

Note known bug.
1. If you try walking under an object you will not be
stopped(although your are stopped at the min z of the
object when jumping)


__

Thanks for commenting so fast btw haha.
 
Last edited:

Kazeon

Hosted Project: EC
Level 33
Joined
Oct 12, 2011
Messages
3,443
I think it's possible to make this MUI without any bad performance issue. First, you can create one rect for every created object. If a unit enters that rect, add that unit to the iteration group. But I need to look at your code first to figure out how to make this MUI (I will do when home) since you don't post the code here.

Despite the fact that this is a cool system, but this is not fully MUI (I don't know is this rule still applied or not) thus it's still not enough to be approved. I will try to help you however.

It should technically be able to support any kind of map with consideration of bugs.
Perhaps you want to mention some examples?
 
I think it's possible to make this MUI without any bad performance issue.
It should be completely possible.
From what I remember my code should be fine for 50 or so units at once, although I haven't done any benchmark tests so I can't say for certain (and I doubt I will).


First, you can create one rect for every created object. If a unit enters that rect, add that unit to the iteration group. But I need to look at your code first to figure out how to make this MUI (I will do when home) since you don't post the code here.
I tried using rects as a solution at first to help with possible efficiency issues.
I found that they are unreliable, inaccurate and in efficient, at least in my case.


Despite the fact that this is a cool system, but this is not fully MUI (I don't know is this rule still applied or not) thus it's still not enough to be approved. I will try to help you however.
Idea no.1
Unit Movement with mouse clicks (allow disabling of the Camera
Arrow structs to be replaced by the normal camera and movement to
be made by clicks)


I'm planning on doing this, hence making this a possible add on in any normal map.
Of course I don't think I'll be able to replicate how units move around normal 2D objects but I don't think that's important.

I think I should be able to pull this off well enough if I put in the time and effort, although atm I am a bit preoccupied by school and other things.


Perhaps you want to mention some examples?
For now it could be used to develop campaigns and any kind of genre to do with controlling a single unit.

__

Cool you uploaded it! I wish you good luck to fix the bugs as good as possible. :)
Thanks Bo!
 

Kazeon

Hosted Project: EC
Level 33
Joined
Oct 12, 2011
Messages
3,443
I tried using rects as a solution at first to help with possible efficiency issues.
I found that they are unreliable, inaccurate and in efficient, at least in my case.
How come? Rects are accurate as far as I noticed. In this case, you don't use rect as collision checking, you just use it to indicate that there is an object around a unit. So the rect doesn't have to be perfectly scaled. You can make it bigger than the object's furthest collision range (that size addition could be added to configuration part called "accuracy" or something).

So on every object generation, create one rect that is a bit bigger than the object's collision size (even 500 range bigger is okay imo). The basic idea is just avoiding ridiculous iteration through the whole objects throughout the world whereas there is no nearby unit around.

Create a trigger with "unit enters created-object's rect" event > when the event is fired then enable the object's collision (add to iteration).

I hope you understand what I mean. I don't know in what case rect is unreliable for your system. Unit enter rect event is fired instantly more than timer expired event as far as I know. This can be a serious improvements since a map won't play around this system with only 50 objects but perhaps hundreds of objects (let's say.. 500? or even more). And I believe iterating through 500 nodes in every 0.03 seconds is nasty.

If you can implement this, perhaps you won't need to iterate more than 50 nodes out of 500! Imagine how better is that.

EDIT:
Why are you recreating the location in your GetLocZ library? It's unnecessary, it creates more speed redundant more than memory efficiency. Perhaps you want to use existing similar system? GetTerrainZ

Hmm.. Now I think if you do this update:
Unit Movement with mouse clicks (allow disabling of the Camera
Arrow structs to be replaced by the normal camera and movement to
be made by clicks)
The system would be even nastier. You really need to implement my suggestion above. If rect is indeed not reliable, you need to figure another way to do this. Read my 500 iteration thingy above? It's just for 1 unit, what if there is 10 units? 5000 iteration per 0.03 seconds. NO

I think you don't need to detect when the object (destructables, etc.) is destroyed/killed. The system should do a more basic task, it's functionality is just to generate a 3D rectangular collision, where the object creation itself should be done by user. Why so? One famous programming expert stated that a great system is not a system that can do as many thing as possible but the vice versa. At first I don't understand why so. But then I realize that statement is incredibly true.

In your case, you only limits the object creation only for units and destructables. But by doing what I suggested in previous paragraph (collision generation thingy) the limit will no longer exist, that means user can create collisions for non-destructable doodads as well. Even though that means more works for user in using your system, but I think it's better to make your system as dynamic as possible, means it can be used in as many cases as possible.

I'm not the best guy to tell you this actually, it's just my preference. Let's wait for others' opinions.
 
Last edited:
I hope you understand what I mean. I don't know in what case rect is unreliable for your system.
...
If you can implement this, perhaps you won't need to iterate more than 50 nodes out of 500! Imagine how better is that.
I've actually already implemented a system of my own like this if you've looked in depth enough into the code (the code isn't exactly simple although I've tried to make it as readable as I can (although I've removed any notes that I don't find useful anymore)).
It checks objects within a square range of 512 (can be changed to any multiple of 2).

Rects are inaccurate and are off their coordinate by 32 in some ways (I used 4 different rects to check destructables because of limited checking of destructibles by rect to help with issues) although this isn't really important considering I know a solution.


What I'm really getting at though is that the code checks the objects in the area of the predicted coordinate,
then if it is changed to a different sector it is then relooped to check the objects in the sector the coordinate has been pushed towards.

This works because I indexed the system to have all the object that intersect within each sector to be in each sector as an almost unique object.


Using rects in this system will become messy and unnecessary and my indexing has kinda out ruled it.

I do see where you are coming from though.

EDIT:
Why are you recreating the location in your GetLocZ library? It's unnecessary, it creates more speed redundant more than memory efficiency. Perhaps you want to use existing similar system? GetTerrainZ
From what I've tested locations only work on the instant it is is created, so I'll look up on this.

I think you don't need to detect when the object (destructables, etc.) is destroyed/killed. The system should do a more basic task, it's functionality is just to generate a 3D rectangular collision, where the object creation itself should be done by user. Why so? One famous programming expert stated that a great system is not a system that can do as many thing as possible but the vice versa. At first I don't understand why so. But then I realize that statement is incredibly true.

In your case, you only limits the object creation only for units and destructables. But by doing what I suggested in previous paragraph (collision generation thingy) the limit will no longer exist, that means user can create collisions for non-destructable doodads as well. Even though that means more works for user in using your system, but I think it's better to make your system as dynamic as possible, means it can be used in as many cases as possible.

I'm not the best guy to tell you this actually, it's just my preference. Let's wait for others' opinions.

I've already made it so you can create 3D objects by hand without destructables and infact they are limited to all the destructables being checked being locked to only creating the destructables at a chosen z coordinate (Wc3 destructable limitation).

So yeh I would rather users don't use the destructable feature unless you have the right situation for it/ understand the limit (I should probably make/find a small tutorial to show how to keep multiple destructables at the same z height as others).

I'll probably make an update to make it an option so when the destructables dies the object doesn't.
 
Level 12
Joined
Feb 11, 2008
Messages
810
Ok this system is really cool and i like how much this could possibly change in the modding community but i noticed something weird how come you can walk over a bridge and its solid but when you go under it and walk up through it it acts like theres nothing there?
 
Simply amazing....

Quiestion: Could work with 3d collisions on units?

It's currently not coded for unit to collide with other unit so they go through them.
Something for a future update.

The whole systems physics are basically coded from scratch so there is a lot of possible things to build onto it.

Ok this system is really cool and i like how much this could possibly change in the modding community but i noticed something weird how come you can walk over a bridge and its solid but when you go under it and walk up through it it acts like theres nothing there?

There hasn't been code created for the unit to stop.
It's something that I have found troubling to find a solution to although I know I can make a solution.

It's completely possible even now to make a work around with creating objects to block a unit from doing this glitch, although I just made the test map to open how functional it is on a simple enough level.
 
Level 9
Joined
Jun 21, 2012
Messages
432
It's currently not coded for unit to collide with other unit so they go through them.
Something for a future update.

The whole systems physics are basically coded from scratch so there is a lot of possible things to build onto it.

I was working on something similar (3d collisions on units) but fail and drop the idea.... will be great if you code it. xD
 
Level 23
Joined
Mar 15, 2012
Messages
2,665
So how many destructible's can this support in the same area around the object? I am really hoping 1000+. As in think of it this way... A multi-level floor where only the current floor is shown to the player to prevent destructible lag. However does the checks for nearby destructible's cause massive lag if there is too many? If so is there any way to limit it to check around the units height instead of a giant circle pillar?
 
Update!

Units should always at least stop at a solid object that is initialized by the system and never go through them.

All System unit functions should also work now (I didn't end up testing them I guess).

Note that removing 3D objects within an area is buggy and mostly nonfunctional atm.

0.4.1.0 Beta

Known bugs

  1. Collision units no longer walk through the bottom of an
    object and not stop, instead the unit is completely stopped
    untill given a direction where it can move freely
  2. Jumping while colliding with a 3D object now works consistently
    although with a trade of still having your single jump when
    walking off an edge of a 3D object
  3. All System Unit functions now work (note: modules can only be
    used once inside a struc.t even when multiple different modules
    that contain one of the same module)
  4. A few grammar errors here and there fixed with the most note
    worthy one being fixed to SystemUnit.Detach and SystemUnit.Detach
  1. Edge of object clipping occurs
  2. Setting a destructables health % to 0 will not remove the
    collision object attached to it
  3. Walking to colide with 3D objects in particular situations will create
    large and unnecesary lag
  4. Remove Rectangle Objects In Rectangle Area function is broken and
    needs to be worked on for debuging
  5. (Not debugable afaik) Walking off the edge of the map will make your units
    model disappear. ((Not tested.) Although it is possible
    to create collision objects outside the edge of the map)
  6. (Not debugable afaik)Creating collision objects with any patch of blizzard water
    will create glitching (must have no indication of blizzard water
    around objects with this system for this system to function)
  7. (Not tested.) If you try and collide with a thin enough object you
    can walk through it
  8. (Not tested.) Removing a 3D collision objects that is attached to
    an destructable before killing the detstructable first will cause bugs
  9. (A possibility.) Some objects may not register or get destroyed properly


Edit:

Finally! It has been released! Testing ASAP!

I'd love to hear your opinion on my system.
Although be sure to check the update before them.

I was working on something similar (3d collisions on units) but fail and drop the idea.... will be great if you code it. xD

It's possible. :p
I can see why anyone would drop the idea though. xD

So how many destructible's can this support in the same area around the object? I am really hoping 1000+. As in think of it this way... A multi-level floor where only the current floor is shown to the player to prevent destructible lag. However does the checks for nearby destructible's cause massive lag if there is too many? If so is there any way to limit it to check around the units height instead of a giant circle pillar?

I don't think this is necessary, although it is possible to code this systems index system to support checking within a 3D box. I can see where your coming from if someone does take this system in a map of their own to a serious level.

You may want to note that destrictables only hold as an attachment to create objects and destroy them when the destrictable is destroyed. Other than that they are just normal destructibles.

It is possible to detect the z height of the unit to make it so destructible and doodads are hidden when at a particular floor.

Btw I might check back later to how many destrictables can be detected within a rect at once.
 
Last edited:
Level 4
Joined
May 15, 2008
Messages
77
Maybe a AI via scripting could make units move in some particular way? this is pure epicness for lack of other words, just a AI like I mentioned before + 3d collision for units + some way for making it terrain or "voxel" like (minecraft like although thats very easy already?) and we could have minecraft for warcraft 3!

Also Im seriously thinking about doing a attack on titan map using this system, I mean there is already some major math and physics there right? until 3D collision for units comes and I develop some kind of AI for the titans, we could have a pvp mode *spoilers from the manga*

Survey corps vs antihuman supression squad: they cast the "shoot" and "reel" skills via a 1rths person view, that way you could maneuver in air and around other obstacles and you try to kill the enemy team like in the manga...

"Training exam" players go all vs all, trying to score "kills" in the forest slashing the necks of the unmobile titan silhouetes from the manga when they train to become soldiers


Anyway, even if we disregard this possible aplication for the system as it is right now, there are other potential uses for it, keep up the amazing job!:thumbs_up:
 
Last edited:
Updated before I go for a couple of weeks for school work

The list isn't to short this time~
This system still has a ton of potential to build on to

Time is limited for me so the Manual on this page is more updated than in the map itself
I wonder how far I got without making bugs?

0.5.0.0 Beta

Known bugs:

  1. The system is now fully MUI
  2. Made seperate functions to allow to be locked to an interface
    unit or the original with the use of ordering the unit around
    with right clicks on terrain (still under construction to work)
  3. Started development of ordering units to move with terrain right
    clicks (for now can only detect where they are ordered and to
    stop instantly)
  4. Added a bunch of functions to break down the different elements
    this system provides with attaching the unit. So now you can break
    down attachment of unit to allow or not the function of attaching
    the Jump ability, player camera lock to unit, arrow detection for
    ordering the unit, having a seperate unit for interface so default
    orders are disabled
  5. Allowed to return Id values of 3D rectangle objects to keep track of
    individual objects (may be buggy though)
  6. Added a function to remove 3D rectangle objects with the object Id
  7. Destroying 3D rectangles within a rectangle area should be fully
    functional now
  8. Added functions to get and set coordinate values for created 3D rectangle
    objects (caution: hasnt been tested much if at all)
  9. Added functions to get coordinate values of units attached to this system
  10. When the system unit is on the ground it can now jump all the time (the
    unit is always locked to the ground when on the ground instead of falling
    off a steap cliff (havent tested this though))
  11. This systems code and general organization has been cleaned a bunch (getting
    the Z value of coordinates is simplified, some functions expanded to help with
    breaking down, understanding and readability and other things)
  12. Updated the manual to add new functions and removed extra descriptions
    (I figured that anyone that can take this system seriously anough should
    be able to understand easlily though anyway without a description and this
    more compact view in a way makes it more readable for quick look ups)
  13. Removed Detach players unit function as this system automatically
    attaches and detached to the owner of the unit
  14. Created a little test demo of when selecting a unit it is locked to the
    selecting player

  1. Edge of object clipping occurs
  2. Setting a destructables health % to 0 will not remove the
    collision object attached to it
  3. Walking to colide with 3D objects in particular situations will create
    large and unnecesary lag
  4. (Not debugable afaik) Walking off the edge of the map will make your units
    model disappear. ((Not tested.) Although it is possible
    to create collision objects outside the edge of the map)
  5. (Not debugable afaik)Creating collision objects with any patch of blizzard water
    will create glitching (must have no indication of blizzard water
    around objects with this system for this system to function)
  6. (Not tested.) If you try and collide with a thin enough object you
    can walk through it
  7. (Not tested.) Removing a 3D collision objects that is attached to
    an destructable before killing the detstructable first will cause bugs
  8. (A possibility.) Some objects may not register or get destroyed properly
    in certain situation

Maybe a AI via scripting could make units move in some particular way?
I may figure something out eventually

this is pure epicness for lack of other words, just a AI like I mentioned before + 3d collision for units + some way for making it terrain or "voxel" like (minecraft like although thats very easy already?) and we could have minecraft for warcraft 3!
I'm not exactly sure about how deep minecraft goes cause I haven't played it much, although this systems physics should be close to it and in a way more advanced eventually. Although you would want to get more closer to minecraft mechanics like the interface and camera as well

Also Im seriously thinking about doing a attack on titan map using this system, I mean there is already some major math and physics there right? until 3D collision for units comes and I develop some kind of AI for the titans, we could have a pvp mode *spoilers from the manga*
Considering the limitation of Wc3 and the fact that Arrow key detection has a delay I wouldn't recomment it for multiplayer combat map, although more for campaigns and other single player maps, although that's for the public to decide

Anyway, even if we disregard this possible aplication for the system as it is right now, there are other potential uses for it, keep up the amazing job!:thumbs_up:

Thanks for the complements!
 
Last edited:
Update!

Change log
0.6.0.0 Beta
  1. Implemented and used Unit Indexer and it's requirments by Nestharus
  2. 3D rectangle data is now stored into real arrays instead of
    hashtables making things more efficiant although passing the OP
    limit for storage
  3. Indexing and general code and variables have been fixed and improved
    with some new functions added
  4. Seperated a folder for global 3D object indexing and other functionality
    an usage with other 3D objects (currently still contains only 3D rectangles)
  5. Seperated a folder for requirment functions that are used through out the
    system
  6. All system unit functionality except 3D objects and requirments are now merged
    into the same folder (merged attach and detach unit methods into there own
    modules)
  7. The jump ability isn't initialized through code anymore and has to be attached
    to the unit through other methods. Any unit that has the ability and is
    attached to the system will have the ability function properly
  8. Updated the Manual and created a seperate disabled trigger for Importing and
    also updated the description for it

Be sure to keep updated if your interesting in my system
 
Update!

Change log
0.6.0.1 Beta
  1. Some slight performance improvements
  2. Infinite loop fixed when movement is redeclaired in a new sector

Cool Man !!!! I think i will use it in my current map.:ogre_love:

I'm thinking of adding customization flexibility for individual unit types and singled out units
This will allow for more than just everyone having the same jump height, movement speed etc

It's kinda pathetic atm when I think about how they don't already lol
Still worth looking into the system atm if your interested though

I would be interested to see anyone using this system in their maps though
Send me a message over PM, VM, email or whatever I don't mind
 
Very nice overall. Some notes of things I'd like to see updated in the future:
  • Documentation. Even if there is an overarching manual, it is nice to have things documented on each trigger (at least a description of what the snippet does). I found myself switching back and forth between the triggers constantly to see where things are implemented/integrated between each other. Now, this may seem like a minor problem--after all, users really only need to read the manual to be able to use the system. But this map is a pretty specific implementation, so it helps to have good documentation so that users can tailor the system to their own map.
  • Encapsulation. A lot of variables are not marked private. If they are meant to be available to the user for access, then each one should be documented in the manual. Else, they should be private. Encapsulation is great in complex systems like this to prevent users from breaking the code.
  • Trigger actions - a lot of your code uses trigger actions. That is fine for normal code, but for dynamic triggers (ones you may destroy), you will want to consider switching to trigger conditions instead. iirc, trigger actions aren't completely removed when DestroyTrigger() is called. Don't quote me on it though--I haven't tested it in a while. So if I'm wrong, ignore this.
  • Check Angle can be reduced to:
    JASS:
    struct Check extends array
        static method Angle takes real Angle returns real
            return ModuloReal(Angle, 360)
        endmethod
    endstruct
    (btw, creating structs like this isn't the best practice. Classes in general are meant to serve as objects, so this would imply having a "Check" object that you are applying "Angle" to. That doesn't make much sense. But that is just random info, there is no need to change it)
  • In GetLocZ, what is the point of StoredZ? It is private, so you can't access it anyway.
  • Consider using Hive's resources for particular systems (e.g. arrow keys, loc Z, Table, etc.). There isn't anything wrong with coding it on your own, but it may create complications when people already have such a system within their map. :) And if possible, you may want to migrate your hashtables over to Table.

Other than that, the code looks nice from what I can tell. I can't give too much feedback on the design since it is a rather large system and its hard to tell what things do what. I'm going to rate it 4/5 for now, but it'll definitely be changed to 5/5 if you can update the documentation. It is a great implementation/approach to a pretty difficult problem. :)
 
Very nice overall. Some notes of things I'd like to see updated in the future:
Thanks for the approval.

  • Documentation. Even if there is an overarching manual, it is nice to have things documented on each trigger (at least a description of what the snippet does). I found myself switching back and forth between the triggers constantly to see where things are implemented/integrated between each other. Now, this may seem like a minor problem--after all, users really only need to read the manual to be able to use the system. But this map is a pretty specific implementation, so it helps to have good documentation so that users can tailor the system to their own map.
Yeh, I'll be sure to add documentation to individual libraries/structs.

  • Encapsulation. A lot of variables are not marked private. If they are meant to be available to the user for access, then each one should be documented in the manual. Else, they should be private. Encapsulation is great in complex systems like this to prevent users from breaking the code.
At lease most that haven't been marked private are accessible in some way.
Eh I'll document some way for it to be user friendly as they would be used in separate libraries/structs anyway.

  • Trigger actions - a lot of your code uses trigger actions. That is fine for normal code, but for dynamic triggers (ones you may destroy), you will want to consider switching to trigger conditions instead. iirc, trigger actions aren't completely removed when DestroyTrigger() is called. Don't quote me on it though--I haven't tested it in a while. So if I'm wrong, ignore this.
I'll see what I can do.

  • Check Angle can be reduced to:
    JASS:
    struct Check extends array
        static method Angle takes real Angle returns real
            return ModuloReal(Angle, 360)
        endmethod
    endstruct
    (btw, creating structs like this isn't the best practice. Classes in general are meant to serve as objects, so this would imply having a "Check" object that you are applying "Angle" to. That doesn't make much sense. But that is just random info, there is no need to change it)
Something I haven't heard of before.

  • In GetLocZ, what is the point of StoredZ? It is private, so you can't access it anyway.
Just a mistake and a last addition to the library.
It doesn't serve any functionality to any of my code at all although just there for completion.

  • Consider using Hive's resources for particular systems (e.g. arrow keys, loc Z, Table, etc.). There isn't anything wrong with coding it on your own, but it may create complications when people already have such a system within their map. :) And if possible, you may want to migrate your hashtables over to Table.
I don't normally like using public resources considering that I don't find them reliable for full functionality or end up having basically useless additions.
I just make my own to keep myself consistent, although I'll be sure to look around again.

I might upload some of my code individually sometime.

Other than that, the code looks nice from what I can tell. I can't give too much feedback on the design since it is a rather large system and its hard to tell what things do what. I'm going to rate it 4/5 for now, but it'll definitely be changed to 5/5 if you can update the documentation. It is a great implementation/approach to a pretty difficult problem. :)
The design may change in design at least slightly with updates as well depending on what I want to add and what I think works best.

So yeh documentation is a big need I guess haha.

Not sure when the next update will be as I'll be updating the documentation with other updates at the same time and that I do have a life lol.
 
^Thanks!

So... Uh, I eventually did the change log to this systems update.
Hopefully I'll break down the manual further to show what users will find useful and when and other stuff.

Updated with added content, changes, replacing, optimizations, documentations etc.
I think I did everything under the list that PurgeandFire listed as well.

This version is a lot more friendly with customization to units in relation to this system.

Change log: 0.6.0.1 beta -> 0.7.0.0 beta
  1. Documentation:
    - Listed out in the manual all the usable functions and variables
    in this system
    - Documented all triggers that are a part of this system
    - Updated the importing documentation a little
  2. Merged, optimized and organized a lot of code
  3. Removed some requirments:
    - ForAllDest
    - GetLocZ
    - CheckAngle
    - IsPlaying
    - InitArrowKey
    - AllowFlight
    Added some new ones:
    - PlayerManager
    - AutoFlight
    - GetTerrainZ
    - ArrowEvent
    - ArriwEvent_PlayerRegister
  4. Setting custimizability:
    - Created settings trigger that contains constant value customizability
    - Created functions and variables the can customize for unit unit types
    (Only works on newly/to be created units)
    - Can customize specific system unit settings at any time
    - Due to custimizability of unit settings, the static method no longer
    use the width and height variables
  5. Collision objects:
    - Added 2D Circle creation
    - Can recreate 3D Rectangles dimensions with other 3D Rectangle Id
    - Can now check if a unit is inside a 3D Rectangle
    - Created some technical functions for indexing collision objects
 
Top