I've been speaking to vjeux on how he does his parsing, and as I said to him the trigger library seems to sort its triggers differently than the GUI library. For example, all of the broken links on the main page for trigger categories are categories that exist in the GUI library that don't in the trigger library (Selection and Unit Selection are actually the same category, but named differently.
It also only factors in the base dependency. It doesn't include triggers from, say, the Campaign library.
I searched in my TriggerString.txt( which is not from the beta) for Campaign.
And i found
ParamDef/Name/lib_Ntve_A28E5377=Campaign
I think The missing link are not there in the beta.
Just search for the similar string in the xml file and then search the xml tag in localisation file.
Use a script language, python ruby perl...
I could use python + a xml parser: beautitulsoup
I was only using the Beta reference because it's all I have handy. My motherboard died on my computer (i'm just using an old laptop to surf the web and email) atm, :(.
I have to say, the TriggerString looks really complicated to me, and to be honest I don't think I could really wrap my head around it, much less write a parser for it. For me at least, it would be much easier to do each trigger individually, even though that would take forever...
It is a translation txt.
use it to copy and past the trigger hint.
And we need really more then just auto generated definition.
some small example could help a lot.
PS: I never read the trigger API ...
The trigger search function is really nice.
I am currently writing about the internal idea of the data editor.
I want understand the xml data.
currently there are only some list about some fields, that is not helpful.
I recommend that the data fields be formatted in a table to match the way the editor display them in Table View.
And then there's the question about how to organize all the data, where a common consensus needs to be formed. Should we attempt to fit every data field, its description, and how to use it, on the same page? Or should each field receive its own page, so that the Data type page only has links to pages for each data field. (ex: Mover would have separate pages for Height Map, Motion Overlays +, Motion Phases +, Pathing Mode, and Placement +). Or maybe only have separate data field pages when you cannot fit the usage info in one line.
Also, the way the main wiki page looks is very sterile. Someone with artistic edge needs to go in there and fix it up.
I use to update the wiki every now and then, but since all the chaos started happening, it was very discouraging to continue.
Avogatro, thx for editing the markup in my pages ;) I'll get to finishing off the effects tab soon...
EDIT:
Onisagi, for the first part, i can try table view for my next page.
Second part, i think that would be way too many pages and linking. I only thought about throwing all the common fields (Like the "Editor" fields, Chance, Response flags, target +, etc.) into a seperate page.
we will change it, because i don't like put a list of action on 1 page either
It is good for people, who write in pure galaxy.
About mover , after i start it, i notice it is much bigger then i thought, so i think we should make the index page for mover from a global view. There are just too many options, that is why i started to write about the GUI of dataeditor.
We should think in mappers point of view.
U got a problem, and u know u need to edit mover.
go to the index page of mover, read it and u should know what mover u really need.
and go deeper.
I think that would be my concept, if u want to help me start seperate pages for movers
then do it. I am not expert on it.
There are quite a few galaxy scripting tutorials on our Wiki actually, :P. And I would prefer not to remove the Galaxy Script from the Triggers as it would help scripters, but for it to act as both a page for scripting and GUI triggering.
I am going to be REALLY sad if you remove the scripting version. As far as I can tell this is the best / only source of info for alot of those functions. If you take that away there is not a lot of references out there if any for some of these functions. I just started getting in to designing a better AI for the game. Please don't pull the rug out from under me. I am not ready :(
I think it can easily work with both scripting AND galaxy side by side. That way it'll work for people that work with only triggers or only galaxy, and also allows people to easily cross reference the two when discussing implementation with other mappers.
I would include the two on the same page but under a separate h1 heading. I could help facilitate the part on how to match galaxy scripts with their corresponding triggers.
The page on each native function is still useful, as we can link to those native description pages on the individual trigger-action/galaxy-script pages.
Avogatro, thx for editing the markup in my pages ;) I'll get to
finishing off the effects tab soon...
EDIT:
Onisagi, for the first part, i can try table view for my next page.
Second part, i think that would be way too many pages and linking. I
only thought about throwing all the common fields (Like the "Editor"
fields, Chance, Response flags, target +, etc.) into a seperate page.
Each field having its own page and descriptions of what it does.... may seem like too many pages/links.... but in the end it will offer more information in a more readable format. So people not looking for that information dont have to swim through it.
But if i want specific information on what that field does for a specific data object. I know right where to go.
BTW I have been making slight changes to the wiki pages you guys have been working on. Hope you dont mind.
Rollback Post to RevisionRollBack
Skype
KageNinpo = SN
My Libraries
DialogLeaderboard & TeamSort
My Projects
SPACEWAR Tribute
Infinite TD
Actually only the link to it is messed up, the data section is slowly comming along but some help from experts would be nice. And the last activity on the wiki was yesterday
Rollback Post to RevisionRollBack
Contribute to the wiki (Wiki button at top of page) Considered easy altering of the unit textures?
Just out of curiosity, is there a way to search the wiki? I have looked and been unsuccessful, and had to manually try and navigate to where I am trying to get to, which is annoying, and sometimes what I am looking for isn't even there.
But yeah, I will start looking into filling in some of the fields that I figure out what they do, but I have to say, there are A LOT of fields that Blizzard doesn't tell us anything about lol
Still discovering some fields function gives you basic practice in designing an experiment and about altering parameters. Also between the campaign dependencies and the left 2 die mod you can at least figure out some.
I've been speaking to vjeux on how he does his parsing, and as I said to him the trigger library seems to sort its triggers differently than the GUI library. For example, all of the broken links on the main page for trigger categories are categories that exist in the GUI library that don't in the trigger library (Selection and Unit Selection are actually the same category, but named differently.
It also only factors in the base dependency. It doesn't include triggers from, say, the Campaign library.
@Abion47: Go
I searched in my TriggerString.txt( which is not from the beta) for Campaign. And i found
ParamDef/Name/lib_Ntve_A28E5377=Campaign
I think The missing link are not there in the beta.
Just search for the similar string in the xml file and then search the xml tag in localisation file. Use a script language, python ruby perl... I could use python + a xml parser: beautitulsoup
Edit: I just copy and past a lot of xmls here: http://www.sc2mapster.com/api-docs/xml-api-docs/
I don't know if i should copy the localisation too. it is big.
I was only using the Beta reference because it's all I have handy. My motherboard died on my computer (i'm just using an old laptop to surf the web and email) atm, :(.
@avogatro: Go
I have to say, the TriggerString looks really complicated to me, and to be honest I don't think I could really wrap my head around it, much less write a parser for it. For me at least, it would be much easier to do each trigger individually, even though that would take forever...
@Sixen: Go
Sorry, dude. That bites.
@Sixen: Go :( Hope u will got new mainboard soon.
@Abion47: Go
It is a translation txt. use it to copy and past the trigger hint. And we need really more then just auto generated definition. some small example could help a lot. PS: I never read the trigger API ... The trigger search function is really nice.
I am currently writing about the internal idea of the data editor. I want understand the xml data. currently there are only some list about some fields, that is not helpful.
Ok i am done. I hope I can help people edit the wiki.
Understand the Meta Concept of Data Editor
@avogatro: Go
Very nice. I'm still trying to get into the triggers. Looks like I need to step it up a notch.
@Abion47: Go
I can write a introduction to trigger xml too.
I recommend that the data fields be formatted in a table to match the way the editor display them in Table View.
And then there's the question about how to organize all the data, where a common consensus needs to be formed. Should we attempt to fit every data field, its description, and how to use it, on the same page? Or should each field receive its own page, so that the Data type page only has links to pages for each data field. (ex: Mover would have separate pages for Height Map, Motion Overlays +, Motion Phases +, Pathing Mode, and Placement +). Or maybe only have separate data field pages when you cannot fit the usage info in one line.
Also, the way the main wiki page looks is very sterile. Someone with artistic edge needs to go in there and fix it up.
I use to update the wiki every now and then, but since all the chaos started happening, it was very discouraging to continue.
Avogatro, thx for editing the markup in my pages ;) I'll get to finishing off the effects tab soon...
EDIT:
Onisagi, for the first part, i can try table view for my next page.
Second part, i think that would be way too many pages and linking. I only thought about throwing all the common fields (Like the "Editor" fields, Chance, Response flags, target +, etc.) into a seperate page.
@onisagi: Go
we will change it, because i don't like put a list of action on 1 page either It is good for people, who write in pure galaxy.
About mover , after i start it, i notice it is much bigger then i thought, so i think we should make the index page for mover from a global view. There are just too many options, that is why i started to write about the GUI of dataeditor.
We should think in mappers point of view.
U got a problem, and u know u need to edit mover. go to the index page of mover, read it and u should know what mover u really need. and go deeper.
I think that would be my concept, if u want to help me start seperate pages for movers then do it. I am not expert on it.
I think the idea of wiki is write together.
I am going to be REALLY sad if you remove the scripting version. As far as I can tell this is the best / only source of info for alot of those functions. If you take that away there is not a lot of references out there if any for some of these functions. I just started getting in to designing a better AI for the game. Please don't pull the rug out from under me. I am not ready :(
I think it can easily work with both scripting AND galaxy side by side. That way it'll work for people that work with only triggers or only galaxy, and also allows people to easily cross reference the two when discussing implementation with other mappers.
I would include the two on the same page but under a separate h1 heading. I could help facilitate the part on how to match galaxy scripts with their corresponding triggers.
The page on each native function is still useful, as we can link to those native description pages on the individual trigger-action/galaxy-script pages.
Each field having its own page and descriptions of what it does.... may seem like too many pages/links.... but in the end it will offer more information in a more readable format. So people not looking for that information dont have to swim through it.
But if i want specific information on what that field does for a specific data object. I know right where to go.
BTW I have been making slight changes to the wiki pages you guys have been working on. Hope you dont mind.
Only field that deserves its own section is the actor events due to their complexity and number of variables.
Contribute to the wiki (Wiki button at top of page) Considered easy altering of the unit textures?
https://www.sc2mapster.com/forums/resources/tutorials/179654-data-actor-events-message-texture-select-by-id
https://media.forgecdn.net/attachments/187/40/Screenshot2011-04-17_09_16_21.jpg
So. Wiki is still not dumped and last activity has been January, 10th.
Does it really take over six months to make new wiki? I wonder. ;)
The answer: Not really, unless they are doing some new revolutionary wiki like software.
Current SC2Mapster wiki on this site has nice amount of knowledge but it is total mess.
Actually only the link to it is messed up, the data section is slowly comming along but some help from experts would be nice. And the last activity on the wiki was yesterday
Contribute to the wiki (Wiki button at top of page) Considered easy altering of the unit textures?
https://www.sc2mapster.com/forums/resources/tutorials/179654-data-actor-events-message-texture-select-by-id
https://media.forgecdn.net/attachments/187/40/Screenshot2011-04-17_09_16_21.jpg
@DrSuperEvil: Go
Just out of curiosity, is there a way to search the wiki? I have looked and been unsuccessful, and had to manually try and navigate to where I am trying to get to, which is annoying, and sometimes what I am looking for isn't even there.
But yeah, I will start looking into filling in some of the fields that I figure out what they do, but I have to say, there are A LOT of fields that Blizzard doesn't tell us anything about lol
Great to be back and part of the community again!
@TacoManStan: Go
Try Google?... I just looked and It says there are 3645 wiki pages.... WOW.
Still discovering some fields function gives you basic practice in designing an experiment and about altering parameters. Also between the campaign dependencies and the left 2 die mod you can at least figure out some.
Contribute to the wiki (Wiki button at top of page) Considered easy altering of the unit textures?
https://www.sc2mapster.com/forums/resources/tutorials/179654-data-actor-events-message-texture-select-by-id
https://media.forgecdn.net/attachments/187/40/Screenshot2011-04-17_09_16_21.jpg