| 09-18-2006, 03:35 AM | #1 | ||||
With the new ability to hack the WE's saving process to allow things like WEHelper. I decided it is time to start VJASS, but I will not focus on OOP syntax from the start but in what we all really 'need' - things that are a priority for me. I will later focus on OOP syntax and mantain backwards compatibility with the features I am gonna add. Let me be serious, I'd like VJASS to be an standard, there really ought to be an standard cause that will let things go on, and I personally like that it would be my standard. Because of that I need suggestions and that kind of things. The first version of VJASS will start fixing what causes the biggest pain to all of us (JASSers and people that use things by JASSers) : Implementing systems. I recon that probably Karukef's preprocessor handles these things already, but I have to deal with the syntax of the preprocessing. The first versions of VJASS will be dumb - not a lot of parsing will be involved, mostly because that's easier for me and that the features I am thinking for it don't seem to require them. The later VJASS will certainly extend the syntax to the OOP level (something like that) . Anyways the main ideas to accomplish are: 1. Syntax that makes sense Of course I could add keywords like "vjass_ppa_0001" but I'd rather try to keep it more like JASS already is to make it less harful. Of course some may argue that it is better not to pretend to be an extension to the language but to make everyone notice it is a preprocessor. I prefer code prettyness over that, what do you think? 2. includes The way includes would work is with something like this:  JASS:include "utilities.vj" function something takes integer i ... ... ... include "scripts\duels.vj" an include line would currently do this: - add the function contents of the include file in that position of the map's script. - add the globals of the include file to the map script's globals block If an attempt to include an already included file is found - nothing happens. Not a warning , and it will certainly not do anything. - Why .vj? The intention is to let people include the script files in the map using the import manager, kind of how the ai editor currently works. This leads to a problem and it is duplicate content. The optimizer or a theorical finalizer should remove these .vj files from the map when we want a release version. To stop the finalizer from removing files it shouldn't remove then we make the vj distinction. This could change if we decide that the finalizer should remove every .j file found in the map that is not scripts\common.j or scripts\blizzard.j Don't worry, cause we will also be able to use relative paths so the files could be outside the map. Like : include ".\commonscripts\handlevars.j" would include a file that is in map's path\commonscripts\ . library Yes, include files work, but are they always good? also, what if the user doesn't like that? Or what about things that require the user to change values, like systems that have config functions? Are include files practical for them? What if to implement a system the user just had to copy a trigger category to the other map? We could just use the custom script section, but, doesn't the custom script section suck? Doesn't it remove modularity? and isn't it too difficult to paste stuff on it? What about replacing? Even I have to copy the whole custom script section to an external editor before adding something to it. We could then just use the triggers, but triggers blow in their own special way, when making the trigger data to script translation, someone forgot that for JASS function position is important ... So you can't just put a trigger in the top and expect it to be added to the script first. So, I thought about the library keyword: JASS:library CSCache version 0.1 prority 1 function CS_H2I takes handle h returns integer return h return 0 endfunction //================================================================================================== // Bunch of other return bug exploiters // function CS_i2r takes integer i returns real return i return 0. endfunction function CS_h2r takes handle h returns real return h return 0. endfunction endlibrary library CasterSystem version 0.1 prority 2 constant function Caster_UnitId takes nothing returns integer return 'e000' //// Caster Unit type rawcode (changes betwen maps, always use it inside '') endfunction constant function Caster_DefaultAttackType takes nothing returns attacktype return ATTACK_TYPE_CHAOS // Default attack type used by the old functions and when you use 0 as DamageOptions endfunction constant function Caster_DefaultDamageType takes nothing returns damagetype return DAMAGE_TYPE_UNIVERSAL // Default damage type used by the old functions and when you use 0 as DamageOptions endfunction constant function DamageTreeDetectorId takes nothing returns integer return 'Aeat' /// The eat tree ability, don't need to change this rawcode unless you modiffied that ability in your map, in that case copy it, reset the copied one and use its rawcode here. endfunction constant function ChangeableFlyingHeightAllowerId takes nothing returns integer return 'Amrf' /// Medivh's Crow form ability, don't need to change this rawcode unless you modiffied that ability in your map, in that case copy it, reset the copied one and use its rawcode here. endfunction constant function CS_MaxCollisionSize takes nothing returns real return 55. //Maximum collision size in your map endfunction constant function CS_Cycle takes nothing returns real return 0.04 // Cycle value for the projectile movement in seconds (Each 0.04 the projectiles get moved) // 0.01 looks smooth but is lag friendly // 0.1 looks horrible but is not laggy // 0.04 is decent for the human eye and quite efficient. // 0.05 would be an improvement in efficiency but probably doesn't look too well endfunction // yadda yadda yadda ... endlibrary The library keyword basically forces VJASS to move the code inside the keyword to the top of the script. all right the library's name and version are just verbose candy, the important thing is priority, for example Caster System requires CSCache, so Caster System can't be added above CSCache. So the usual process would be detecting all library blocks, sort by priority and add them to the top of the scripts. Kind of good, isn't it? Globals Now the globals block is certainly required, do we all agree we are tired of declaring globals with the variables dialog, being forced to use the udg_ preffix, not being able to use region, or handle typed globals. Or what about asking users to add the globals or to use a trigger to copy the globals? That's extremely lame if you ask. So vjass would just be able to find global blocks: JASS:globals gamecache cscache = null integer array udg_csarray1 integer array udg_csarray2 integer array udg_csarray3 location array udg_csfreeindexes endglobals In random positions of the script and then just put them all in the same globals block at the top of the script. I think we all need this . What I want Do you notice how good is this? Besides of letting people like me code everything in external .vj files and then just merge the script . It also allows me to make my sytems much easier to implement: How to implement the caster system:
... |
| 09-18-2006, 04:07 AM | #2 |
| 09-18-2006, 04:19 AM | #3 |
| 09-18-2006, 04:32 AM | #4 |
| 09-18-2006, 04:50 AM | #5 |
| 09-18-2006, 12:43 PM | #6 |
| 09-18-2006, 12:57 PM | #7 |
| 09-18-2006, 12:59 PM | #8 |
| 09-18-2006, 01:09 PM | #9 |
| 09-18-2006, 02:53 PM | #10 |
JASS:define DamageTreeDetectorId 'Aeat' define CS_Cycle 0.04 include castersystem Code:
#set DamageTreeDetectorId 'Aeat' #set CS_Cycle 0.04 #use castersystem #unset CS_Cycle #ifset CS_Cycle call wiie() #else call hmhm() #endif |
| 09-18-2006, 03:29 PM | #11 |
| 09-18-2006, 04:01 PM | #12 |
| 09-18-2006, 04:36 PM | #13 |
| 09-18-2006, 06:05 PM | #14 |
all right this is the result of wondering and not the result of reading pitzermike's link yet: * ifdef is cool but I found out that it will be really problem friendly with libraries. And pipe is right about code problems JASS:library CSCache version 13.8 ... endlibrary library CasterSystem version 13.8 requires CSCache, AnotherLibrary, YetAnotherLibrary /// .... endlibrary Even so we could make something like requires CSCache 13.8 so it could even pop up error messages about versions before pjass complaining about missing functions. Edit: Funny , when I was thinking around how to make the requires keyword work I accidentally made an algorithm like topsort o_O |
| 09-18-2006, 06:30 PM | #15 |