You can use the initializer library functionally.. Any dependancies will be run before the current initializer. It will be faster to write with a simple integer, but harder to maintain if you share code with multiple people, like if you use libraries that use initializers.
Initializer(LibraryName="Run me last",LibraryVersion="1",RequiredLibraries="Run me first:1"){}Initializer(LibraryName="Run me first",LibraryVersion="1"){}
Are you sure the int[0] i; presists to galaxy code? It should be removed.
Also, it's impossible check at compile time if you create a dynamic array of size 0 - You could use the returned value of a function, and well.. Rice's theorem.
And a question: Is implicit resizing supported? I cannot test the result right now, but writing
int[]i=newint[5]();i[10]=5;
throws no error for me.
No. It is not supported, though it will work. The only issue with it is that when you delete i, it will only remove elements up to the specified length of the array.
There's also an issue that you can't "right-click" warnings such as "unused struct: MyStruct", as that activates the error box which says it is unable to open the file. The label stating where the struct is declared seems to not be set properly either, as it says "Library file[1, 8]: Unused struct: MyStruct" when my struct isn't originating from any library.
Hell, it's about time - Version 3.0.0 is finally here :)
I don't think that it is bug free though. So much code as been written, so there are likely to still be bugs lurking around.. If it's horrible, remember that you can downgrade in Help->Change to another version.
I just had a look at your bug. It is caused by an incorrect update to my control flow graph, after removing an unused local assignment. I will fix it for next version of course, but you should be able to fix it by removing your unused local assignments.
if(id==0){k=350;}else{k=150;}//In your code, this value of i is not being read.i=libNtve_gf_CreateDialogItemLabel(d,400,k,c_anchorTopLeft,75,95,GetUnitTooltip(id),Color(100,100,100),false,2.0);
So far, I should have the compiler part done, and about half of the suggestion list done. But once I get that done, there will be some time with bug fixing.
The compiler is written in c#. It's probably not be a bad idea to bring others aboard for faster updates - although there are a lot of code for someone to wrap his head around - and that's probably even harder right now where the code won't compile.
Hmm.. that looks weird.. I'm still working on the big rewrite and fixing its bugs though. Before I get that done, I can't really release any bug fixes, because the program is too unstable - at this point I got error reports popping up all the time :).
I know it's been a while, but changing the naming really has ramifications everywhere.. Also, as I said earlier, I do have other things to do apart from this project.
Anyway.. only advice I can really give right now is to use fields when it bugs on you like that.. It shouldn't join them.
The reason initializers are in one trigger pr initializer is the limit on the ammount of stuff that can be done in one trigger. With loops and stuff, I have no way of know how much stuff one initializer is doing. Putting them all into one trigger could reach the limit.
What is the difference between TruncI(fixed) and FixedToInt(fixed)?
if you write int i = (int) f; it will insert a call to FixedToInt. I don't think I will create an implicit conversion from fixed to int, since as you say, we lose information.
I still have no problems, if I add the code in an initializer along with your code. I did make an error in the code I posted previously though.. The array is not created.. The first statement should be
It outputs 10, 5 as expected. Same thing if I declare PlayerData as a struct - though if you only use it in dynamic contexts, use classes.
Also, you don't really need the StringToText calls.. As long as you didn't define an overload for the function that takes ints in second parameter, the compiler will convert it to text on its own.
No, I don't really have a master plan as to what features are to come.. I kind of take it one step at the time. For next one, I'm adding reliable null pointer checks, nested namespaces, and probably some bugs because of all of this rewriting. I also think I'll allow sync/async invokes on more than just global methods.
You can't. There is no way for me to reliably send parameters to triggers when their event is fired, so It would be hard to tell the trigger what class object it is currently in. Therefore, triggers inside structs/classes are not possible. You could argue that it should still be possible with static methods, but it currently isn't.
When I need something like that, I usually have a list of all allocated classes (Add to the list in the constructor, and remove from it in the deconstructor). Then I make a global trigger, that runs through each allocated object, and does what it needs to do. Like this
usingCollectionsInitializer{Test.Instances=newArrayList<Test*>();}classTest{//I uploaded a library containing the arrayliststaticArrayList<Test*>*Instances;inti;boolrunTriggerOnMe;Test(inti,boolrunTriggerOnThis){Instances->Add(this);this->i=i;runTriggerOnMe=runTriggerOnThis;}~Test(){Instances->Remove(this);}}TriggerTestTrigger{events{TriggerAddEventUnitStartedAttack(TestTrigger,null);}actions{intcount=Test.Instances->Count;//No need to call this each iteration - unless you modify the collectionfor(inti=0;i<count;i++){Test*test=Test.Instances->Get(i);if(test->runTriggerOnMe){//Do stuff}}}}
Well.. yes, but it is because your variable is a pointer (although you have to make it a pointer when you use classes). You can make pointers to other stuff as well, and then you also have to use * or ->. Like
You can use the initializer library functionally.. Any dependancies will be run before the current initializer. It will be faster to write with a simple integer, but harder to maintain if you share code with multiple people, like if you use libraries that use initializers.
@Kueken531: Go
Are you sure the int[0] i; presists to galaxy code? It should be removed.
Also, it's impossible check at compile time if you create a dynamic array of size 0 - You could use the returned value of a function, and well.. Rice's theorem.
Thanks guys, Ill get to work on fixing them.
No. It is not supported, though it will work. The only issue with it is that when you delete i, it will only remove elements up to the specified length of the array.
Edit:
How exactly do you define this 0 sized array? I thought I fixed that one.
I can't replicate this one : / you got some code?
Hell, it's about time - Version 3.0.0 is finally here :)
I don't think that it is bug free though. So much code as been written, so there are likely to still be bugs lurking around.. If it's horrible, remember that you can downgrade in Help->Change to another version.
@Kueken531: Go
I just had a look at your bug. It is caused by an incorrect update to my control flow graph, after removing an unused local assignment. I will fix it for next version of course, but you should be able to fix it by removing your unused local assignments.
So far, I should have the compiler part done, and about half of the suggestion list done. But once I get that done, there will be some time with bug fixing.
@Wyatt124: Go
The compiler is written in c#. It's probably not be a bad idea to bring others aboard for faster updates - although there are a lot of code for someone to wrap his head around - and that's probably even harder right now where the code won't compile.
@Kueken531: Go
What I meant was to use global fields instead of local variables. It won't merge a field with a local variable.
If the g
++
compiler can generate invalid code, then that is a bug, so arrays of size 0 should be reported as an error, or removed by the compiler.Hmm.. that looks weird.. I'm still working on the big rewrite and fixing its bugs though. Before I get that done, I can't really release any bug fixes, because the program is too unstable - at this point I got error reports popping up all the time :).
I know it's been a while, but changing the naming really has ramifications everywhere.. Also, as I said earlier, I do have other things to do apart from this project.
Anyway.. only advice I can really give right now is to use fields when it bugs on you like that.. It shouldn't join them.
So much to do, so little time :( I got some less optional projects demanding time as well..
The error server should be back up - sorry about that.
@Slarti: Go
The reason initializers are in one trigger pr initializer is the limit on the ammount of stuff that can be done in one trigger. With loops and stuff, I have no way of know how much stuff one initializer is doing. Putting them all into one trigger could reach the limit.
@Kueken531: Go
If you look at some generated dialog code, you will find a secret unannounced cast :)
I didn't add it to the documentation, or announce it in a changelog, because I kind of dislike it, but it is needed in some situations.
What is the difference between TruncI(fixed) and FixedToInt(fixed)?
if you write int i = (int) f; it will insert a call to FixedToInt.
I don't think I will create an implicit conversion from fixed to int, since as you say, we lose information.
I still have no problems, if I add the code in an initializer along with your code. I did make an error in the code I posted previously though.. The array is not created.. The first statement should be
Maybe that is your problem too.
I might need more of your code than that. When I run the following script
It outputs 10, 5 as expected. Same thing if I declare PlayerData as a struct - though if you only use it in dynamic contexts, use classes.
Also, you don't really need the StringToText calls.. As long as you didn't define an overload for the function that takes ints in second parameter, the compiler will convert it to text on its own.
Thx :)
No, I don't really have a master plan as to what features are to come.. I kind of take it one step at the time. For next one, I'm adding reliable null pointer checks, nested namespaces, and probably some bugs because of all of this rewriting. I also think I'll allow sync/async invokes on more than just global methods.
Woo! Today it is one year since the first release of the editor. :)
I had hoped to get next version out for today, but those nested namespaces requires a hell of a lot of rewriting..
You can't. There is no way for me to reliably send parameters to triggers when their event is fired, so It would be hard to tell the trigger what class object it is currently in. Therefore, triggers inside structs/classes are not possible. You could argue that it should still be possible with static methods, but it currently isn't.
When I need something like that, I usually have a list of all allocated classes (Add to the list in the constructor, and remove from it in the deconstructor). Then I make a global trigger, that runs through each allocated object, and does what it needs to do. Like this
Well.. yes, but it is because your variable is a pointer (although you have to make it a pointer when you use classes). You can make pointers to other stuff as well, and then you also have to use * or ->. Like
This can be used when any modifications other methods make to your variable should be saved. When you run foo, 42 will be displayed on screen.