[Idea] [system] (vJass) CustomMissle

Status
Not open for further replies.
I haven't actually seen the system (I suppose you haven't either), so I guess both of our comments are kind of irrelevant. I was merely saying that it sounds like he's just being lazy and using xe.
 
Well, if you call it lazy when I use open-source system that are already made and fit my needs then yes, I am lazy. For all others I am just using the opensource stuff because its open-source and exactly what I am looking for.

About the xe-stuff: I will use xepreload, xefx, xedamage and xecast in the missle system. I don't see why I have to recreate it myself.

You guys really miss the point in doing opensource librarys.
 
Alot of cool features there. But if you want to make a good system. Make it standalone that is compatible with the rest. Because importing vJass is already pain in the ... Importing a useful system requires more importing of other system is just...

If you can try to make it standalone. I might actually use it. Most of the time i skip vJass spells/system is because they have a bunch of things to import before i can actually use something.

Just my opinion though. Subscribed [:
 
I remember you said the same thing to one of my system where you won't be bothered to import to use since it is such troublesome when one only need to copy and paste triggers. So i am just giving you the same idea. Make it easier for people to import and this system will be good [: Just my idea though. It is always good to make things easier for importing stuff since you said you are going to replace xe on your 1st post, you should stick with your idea.

In the end is up to you [: i will still be looking forward to this project.
 
How would making optional requirements hinder its functionality in any way?

Anachron said:
Open-source systems should never be optional.
Click to expand...

What exactly do you think Vexorian added the optional keyword for then?

Everything done in the World Editor is open-source, and there are plenty of scripts that use the optional keyword on their requirements. There is no excuse to not maximizing the diversity of your code. The only explanation is that you don't want to make it optional so its easier to code.

Either way I've posted the code to my Projectiles library in a separate thread for optimization criticism.
 
Not long. I was just doing some tests yesterday (I've been optimizing it like crazy) though to see how well the unit-enumeration worked with spread-out units (because with a pack of 70+ units it obviously lags a bit) and it seems to handle 250+ projectiles without dropping much frame-rate (and this is on a relatively out-dated computer). Of course, having 330+ units visible at once is rather stressful on the processor in the first place.

The only problem that arose was trying to get projectile-projectile collision working perfectly, though I do not think it will be included in the system (this release, anyways) because my understanding of continuous collision detection is insufficient, and the alternative option is less efficient.

I should really post a submission thread though so I can get some feedback as to the functionality that the system should include. Currently projectiles have "options" for different sorts of functionality, for instance if you do set someProj.activeUnitCollision = false the projectile will not longer execute the .onUnitCollision interface method.

It should be soon though.

Oh, I also need to add some projectile-enumeration functions so that the user can reference the projectiles he creates without having a direct reference to them.
 
Well the interface methods are:

JASS: 
method onFinish
method onBirth
method onUnitCollision
method onGround

Other than that, you can modify the projectile by using these "setup" variables:

JASS: 
boolean activeUnitCollision
boolean activePitchRotation

The active-pitch-rotation was recently brought over from an extension struct so that I could remove the onLoop virtual method (since it is very inefficient), and should typically be used with the dummy.mdx model with various pitch animations.

JASS: 
real collision
real scale
real timescale

These are available to the user to modify values in real-time. Scale modifies the size of the projectile, time-scale modifies the "slow-motion" effect on the projectile (allows the projectile to be stopped, slowed down, or sped up in the middle of its flight). Collision simply affects the radius of the projectile.

The projectiles are initialized by specifying a unit (you do not have to imitate WarCraft III projectiles, instead you could make a unit a projectile to simulate a "jump" or something) and then launched by method doLaunch which takes various parameters to setup the projection sequence. It uses vectors for the starting point/ending point however if the ending point is changed in the middle of the flight it will activate projectile "homing".

The dynamical aspect of the system comes from the fact that projectile is a data-struct that can be extended, opening the door to any user-customizations. By default, the projectile struct doesn't require a "source" unit or a "target" unit, instead these things can be added by extending the struct. For example:

JASS: 
struct war3missile extends projectile
    unit    source      = null
    unit    target      = null
    
    method onFinish takes nothing returns nothing
        call UnitDamageTarget(source, target, ...)
        call .destroy()     //* If .onFinish is not declared, this is done automatically.
    endmethod
endstruct

Once you've launched your projectile, what you have declared here will dictate how the projectiles reacts when predefined events take place. For example, when the projectile is "finished" its trajectory, it will cause the specified source unit to damage the specified target unit.

To be honest this isn't a system for noobs, and I'm not trying to show off how many things you can do with it, because the possibilities are end-less. If the user extends the projectile struct he/she can pretty well do whatever he/she wants with it.
 
Okay guys, I am reviving this.

The main library has again been rewritten, now I don't use XE anymore.
XE is a really old system right now and shouldn't be used.

The new system allows the following interfaces (right now):
JASS: 
        private stub method onUnitTouch takes unit theUnit returns nothing
        endmethod
        
        private stub method onCollide takes thistype theCollider returns nothing
            call .destroy()
        endmethod
        
        private stub method onFly takes nothing returns nothing
        endmethod
        
        private stub method onStart takes nothing returns nothing
        endmethod
        
        private stub method onEnd takes nothing returns nothing
        endmethod
        
        private stub method accelerate takes nothing returns nothing
            set .moveSpeed = .moveSpeed + CM_PERIOD * .acceleration
        endmethod
        
        private stub method flyCheck takes nothing returns boolean
            return true
        endmethod
 
Status
Not open for further replies.

Similar threads

Anachron
  • Locked
[JASS] (vJass) Inheritance problem
Replies
3
Views
2K
Anachron
Anachron
Justify
  • Locked
Unit movement, cyrcle
Replies
2
Views
1K
Justify
Justify
ProFeT
  • Locked
[JASS] JCast (advanced casting-system)
Replies
19
Views
5K
ProFeT
ProFeT
Justify
  • Locked
[JASS] Missle (not) moving
Replies
10
Views
2K
Justify
Justify
Ciebron
  • Locked
[JASS] Dubbel free
Replies
12
Views
2K
Deaod
Deaod
Back
Top