User talk:BryanDerksen - Revision history

BryanDerksen at 01:21, 10 November 2009

2009-11-10T01:21:55Z

Languard at 17:56, 9 November 2009

2009-11-09T17:56:41Z

BryanDerksen: /* Collisions and Disambiguation */

2009-07-27T19:31:11Z

‎Collisions and Disambiguation

Sunjammer at 19:22, 27 July 2009

2009-07-27T19:22:04Z

BryanDerksen: /* Collisions and Disambiguation */ I like it

2009-07-27T19:06:18Z

‎Collisions and Disambiguation: I like it

Sunjammer: /* Collisions and Disambiguation */ new section

2009-07-27T18:44:21Z

‎Collisions and Disambiguation: new section

BryanDerksen: Moving to the talk page of the template in question

2009-07-21T21:58:03Z

Moving to the talk page of the template in question

Sunjammer at 21:17, 21 July 2009

2009-07-21T21:17:48Z

BryanDerksen: add a header to the function conventions discussion

2009-07-21T17:59:40Z

add a header to the function conventions discussion

BryanDerksen: sounds good. I'll mock it up, though it'll be nonfunctional until parserfunctions is installed.

2009-07-21T15:14:34Z

sounds good. I'll mock it up, though it'll be nonfunctional until parserfunctions is installed.

@@ Line 26: / Line 26: @@
 ::: In the final analysis there's only going to be a handful of conflicts, and there are tools out there for MediaWiki that are specifically designed to make disambiguation easy, so we can try out different solutions without worrying too much about getting locked into something suboptimal. Do what you need to do to get the raw data in, I can clean up afterward. :) [[User:BryanDerksen|BryanDerksen]] 19:31, 27 July 2009 (UTC)
-----
+== Wacom tablets==
 A friendly poke to remind you that you were going to ask around for details on using Wacoms with terrain mesh editing.  I also posted my settings to my talk page if you wish to take a look. [[User:Languard|Languard]] 17:56, 9 November 2009 (UTC)

← Older revision		Revision as of 17:56, 9 November 2009
Line 25:		Line 25:

	::: In the final analysis there's only going to be a handful of conflicts, and there are tools out there for MediaWiki that are specifically designed to make disambiguation easy, so we can try out different solutions without worrying too much about getting locked into something suboptimal. Do what you need to do to get the raw data in, I can clean up afterward. :) [[User:BryanDerksen\|BryanDerksen]] 19:31, 27 July 2009 (UTC)		::: In the final analysis there's only going to be a handful of conflicts, and there are tools out there for MediaWiki that are specifically designed to make disambiguation easy, so we can try out different solutions without worrying too much about getting locked into something suboptimal. Do what you need to do to get the raw data in, I can clean up afterward. :) [[User:BryanDerksen\|BryanDerksen]] 19:31, 27 July 2009 (UTC)
		+
		+	----
		+	A friendly poke to remind you that you were going to ask around for details on using Wacoms with terrain mesh editing. I also posted my settings to my talk page if you wish to take a look. [[User:Languard\|Languard]] 17:56, 9 November 2009 (UTC)

← Older revision		Revision as of 19:31, 27 July 2009
Line 21:		Line 21:

	:: I'd be inclined toward decorating the data type if for no other reason than I want to differentiate between the '''dascript''' data types and '''2da''' data types. Since we have to decorate one regardless of the approach it makes sense to decorate both and leave functions alone. "One rule to ring them all and in the wiki find them" as Tolkien might have said. It also means I don't have to change the code that updates generates the dascript.php only the template (j/k)! --[[User:Sunjammer\|Sunjammer]] 19:22, 27 July 2009 (UTC)		:: I'd be inclined toward decorating the data type if for no other reason than I want to differentiate between the '''dascript''' data types and '''2da''' data types. Since we have to decorate one regardless of the approach it makes sense to decorate both and leave functions alone. "One rule to ring them all and in the wiki find them" as Tolkien might have said. It also means I don't have to change the code that updates generates the dascript.php only the template (j/k)! --[[User:Sunjammer\|Sunjammer]] 19:22, 27 July 2009 (UTC)
		+
		+	::: Heh. Well, I'm not sure that we really need separate articles for 2da and script types - the only differences I can think of offhand are [[bool]] and [[comment]] lacking a scripting equivalent (which renders them a moot problem since scripts will never have a link to them in the first place) and the way a [[resource]] literal has an 'R' prefix in scripting but not in 2das. But again, since we've got access to redirects now I guess it's easier to start with them separate and merge them later if that turns out to be better.
		+
		+	::: In the final analysis there's only going to be a handful of conflicts, and there are tools out there for MediaWiki that are specifically designed to make disambiguation easy, so we can try out different solutions without worrying too much about getting locked into something suboptimal. Do what you need to do to get the raw data in, I can clean up afterward. :) [[User:BryanDerksen\|BryanDerksen]] 19:31, 27 July 2009 (UTC)

← Older revision		Revision as of 19:22, 27 July 2009
Line 19:		Line 19:

	:I like it, and was thinking something similar. However, I wonder if perhaps the data type should get the unadorned title rather than the function, since they're going to be linked to far more frequently - they're linked to from the variable table templates and the 2da templates, for example, and I expect that in ordinary written prose a link "[[vector]]" is more likely to be aimed at the data type than the constructor function. Ultimately it's not that big a deal which way we pick since we have redirect capabilities in this wiki, and since most of the links will be generated via templates or scripts so they can be easily changed if we end up picking the suboptimal approach. [[User:BryanDerksen\|BryanDerksen]] 19:06, 27 July 2009 (UTC)		:I like it, and was thinking something similar. However, I wonder if perhaps the data type should get the unadorned title rather than the function, since they're going to be linked to far more frequently - they're linked to from the variable table templates and the 2da templates, for example, and I expect that in ordinary written prose a link "[[vector]]" is more likely to be aimed at the data type than the constructor function. Ultimately it's not that big a deal which way we pick since we have redirect capabilities in this wiki, and since most of the links will be generated via templates or scripts so they can be easily changed if we end up picking the suboptimal approach. [[User:BryanDerksen\|BryanDerksen]] 19:06, 27 July 2009 (UTC)
		+
		+	:: I'd be inclined toward decorating the data type if for no other reason than I want to differentiate between the '''dascript''' data types and '''2da''' data types. Since we have to decorate one regardless of the approach it makes sense to decorate both and leave functions alone. "One rule to ring them all and in the wiki find them" as Tolkien might have said. It also means I don't have to change the code that updates generates the dascript.php only the template (j/k)! --[[User:Sunjammer\|Sunjammer]] 19:22, 27 July 2009 (UTC)

← Older revision		Revision as of 19:06, 27 July 2009
Line 17:		Line 17:
	What do you think?		What do you think?
	--[[User:Sunjammer\|Sunjammer]] 18:44, 27 July 2009 (UTC)		--[[User:Sunjammer\|Sunjammer]] 18:44, 27 July 2009 (UTC)
		+
		+	:I like it, and was thinking something similar. However, I wonder if perhaps the data type should get the unadorned title rather than the function, since they're going to be linked to far more frequently - they're linked to from the variable table templates and the 2da templates, for example, and I expect that in ordinary written prose a link "[[vector]]" is more likely to be aimed at the data type than the constructor function. Ultimately it's not that big a deal which way we pick since we have redirect capabilities in this wiki, and since most of the links will be generated via templates or scripts so they can be easily changed if we end up picking the suboptimal approach. [[User:BryanDerksen\|BryanDerksen]] 19:06, 27 July 2009 (UTC)

← Older revision		Revision as of 18:44, 27 July 2009
Line 2:		Line 2:

	Moved to [[Template talk:dafunction]]		Moved to [[Template talk:dafunction]]
		+
		+	== Collisions and Disambiguation ==
		+
		+	Your change to the [[Vector]] page and categorisation of [[Bool]] as a [[Data type]] started me thinking about how to best handle these.
		+
		+	Putting information for both '''Vector''' and '''vector''' on the same page would be very confusing especially if GeSHi is configured to create links for functions ''and'' data types (which is what I've set it up to do). Which ever way we do it half of the time a user will be taken to what initially appears to be the wrong page which will be frustrating for the user. Moreover since there are other such collisions: '''Effect''' vs '''effect'''; '''Event''' vs '''event'''; and '''Location''' vs '''location''' a simple and consistent solution is desirable.
		+
		+	Similarly while '''Bool''' itself doesn't present any problem, unless people try to use it in dascript, there will be collisions with the other 2da data types: '''int''', '''float''', '''string''', etc. Again if someone is wanting information on 2da we don't want them having to wade through the dascript information first.
		+
		+	Consequently suggestion would be to leave the functions undecorated but add a suffix to the data types to differentiate them from the functions and from each other. I've seen this on wikipedia where you get [http://en.wikipedia.org/wiki/Iron_Maiden Iron Maiden], [http://en.wikipedia.org/wiki/Iron_Maiden_(album) Iron Maiden (album)] and [http://en.wikipedia.org/wiki/Iron_Maiden_(song) Iron Maiden (song)]. In this case I would suggest adding "(dascript type)" or "(data type)" and "(2da type)" as appropriate.
		+
		+	This suffix would be supported in the GeSHi config file so for the most part it would be invisible to the user. Only when they were searching specifically for a Vector or vector would they actually become aware of what was going on.
		+
		+	What do you think?
		+	--[[User:Sunjammer\|Sunjammer]] 18:44, 27 July 2009 (UTC)

@@ Line 1: / Line 1: @@
 == Function article conventions ==
-At some point I'll certainly dive in to the whole wiki but my primary concern right now is generating the pages for the scripting section.  I have an application (the same one I used to produce the [http://www.sunjammer.co.uk/assets/misc/dascript.zip dascript.php] GeSHi configuration file) which would be capable of mass producing the pages for each native function and helping to produce the pages for the constant groups which can then all be loaded into the wiki ''en masse''.  In order to do this though we (as a group) need to decide on the naming conventions (i.e. do we add a prefix, suffix, nothing) and the basic layout of the page.  I would also like to avoid putting example scripts directly on the page and instead transclude them from a "script library" section.  That way if we need to/want to correct an example we only need to do it once.
+Moved to [[Template talk:dafunction]]
---[[User:Sunjammer|Sunjammer]] 00:31, 21 July 2009 (UTC)
-−
-:If we put the consistent stuff (name, parameters, return value, etc.) into a template or a set of templates when we auto-generate the script pages, we'll be able to update the layout of the page later on without having to re-edit everything. I was planning on doing that with the event types that I just spent a bit of time splitting out into individual articles but since we don't currently have the parserfunctions extension installed I couldn't come up with something robust enough for my tastes - I'll go back and re-edit those pages later on when we do (parserfunctions are definitely at the top of my "we need this" list right now).
-−
-:What I'm thinking is a template that takes something like the doxygen headers already in place on some of the existing functions. So this:
-−
-<dascript>
-/** @brief Returns a creature with a specifc AI Status
-−
-* When looking for a target of type SELF: the function will return OBJECT_SELF if the status is valid
-* When looking for a target of type ALLY: the function will return the nearest ally with the status
-* When looking for a target of type ENEMY: the function will return the nearest enemy with the status
-−
-* @param nAIStatus the status being checked for if active on a creature
-* @param nTargetType the target type of creature we are looking for that might have the specified status
-* @param nCommandType type of command - if ability the condition will avoid returning an enemy that has an ability applied
-* @param nCommandSubType subtype of command - if ability the condition will avoid returning an enemy that has an ability applied
-* @returns A creature of a specific type (self, ally, hostile) that has the status applied, OBJECT_INVALID otherwise
-* @author Yaronv
-*/
-object _AI_Condition_GetCreatureWithAIStatus(int nAIStatus, int nTargetType, int nCommandType, int nCommandSubType, int nTacticID);
-</dascript>
-−
-:Would get turned into this:
-−
-<pre>
-{{dafunction header
-|name = _AI_Condition_GetCreatureWithAIStatus
-|brief = Returns a creature with a specifc AI Status
-|param1type = int
-|param1name = nAIStatus
-|param1desc = the status being checked for if active on a creature
-|param2type = int
-|param2name = nTargetType
-|param2desc = the target type of creature we are looking for that might have the specified status
-−
-−
-−
-|returnstype= object
-|returnsdesc= A creature of a specific type (self, ally, hostile) that has the status applied, OBJECT_INVALID otherwise
-|sourcefile= ai_conditions_h
-|sourcemodule= Core Resources
-}}
-</pre>
-−
-:Which, via the magic of templating and fancy parserfunctions and whatnot, gets turned into a beautifully-formatted informational header at the top of the article. If the function doesn't have good doxygen comments the template would have empty desc fields left for editors to fill in later on.
-−
-:My inclination for article naming conventions is to not have any prefixes or whatnot, to make linking easier - just throw [[]] around the function's name and you're there. [[User:BryanDerksen|BryanDerksen]] 00:55, 21 July 2009 (UTC)
-−
-:Oh, your transcludable example script library is a good idea, too. I didn't address it above because it won't need to have as much standardization set in stone from the outset. :) [[User:BryanDerksen|BryanDerksen]] 01:01, 21 July 2009 (UTC)
-−
-:: I assume the goal is to create user-friendly pages that look something like the [http://www.nwnlexicon.com/compiled/function.actionattack.html NWN Lexicon's pages] or MSDN?  If that is the case can you can mock up a single (for example [[CreatePool]] since it already exists), export it and upload the XML to the Social Site (or email it to me directly)? I can then tweak my application and produce a test page, send you the XML which you can import into the Wiki.  If all goes well and we are happy with the results I can the produce a page for all 600+ core function in script.ldf at the touch of a button! I can also produce an updated version of the GeSHi config file. After that we can repeat the process for the various core libraries as required.
-−
-:: I would also suggest that rather than putting everything under a single '''Script''' category we use different categories to distinguish between the DAScript language (i.e. the reference material) and articles on scripting in DA (i.e. the instructional material). I think '''DAScript''' for the reference material and either '''DAScripting''' or '''Scripting''' for the instructional material.
-−
-:: --[[User:Sunjammer|Sunjammer]] 11:46, 21 July 2009 (UTC)
-−
-::: Yeah, I wouldn't want to put 600 articles under one category anyway :) (except for purely housekeeping reasons, perhaps). We'll probably want to categorize these things based on what sort of function they perform, so we could have [[:category:character generation functions]], [[:category:event functions]], and so forth. Seems likely to me that this is how they'll usually be referenced, a builder will have a particular task he wants to do and will want to see what functions are relevant to it. I'll mock up a nonfunctional version of the template today since I've already got a good start on the parameters we'll need up above, and solicit some more input from scripters on the beta forum to make sure I'm not overlooking anything basic. [[User:BryanDerksen|BryanDerksen]] 15:14, 21 July 2009 (UTC)
-−
-:::: I've added an alternative version of the mock up on my [[User_talk:Sunjammer|Discussion]] page.  Let me know what you think.
-:::: --[[User:Sunjammer|Sunjammer]] 21:17, 21 July 2009 (UTC)

← Older revision		Revision as of 21:17, 21 July 2009
Line 60:		Line 60:

	::: Yeah, I wouldn't want to put 600 articles under one category anyway :) (except for purely housekeeping reasons, perhaps). We'll probably want to categorize these things based on what sort of function they perform, so we could have [[:category:character generation functions]], [[:category:event functions]], and so forth. Seems likely to me that this is how they'll usually be referenced, a builder will have a particular task he wants to do and will want to see what functions are relevant to it. I'll mock up a nonfunctional version of the template today since I've already got a good start on the parameters we'll need up above, and solicit some more input from scripters on the beta forum to make sure I'm not overlooking anything basic. [[User:BryanDerksen\|BryanDerksen]] 15:14, 21 July 2009 (UTC)		::: Yeah, I wouldn't want to put 600 articles under one category anyway :) (except for purely housekeeping reasons, perhaps). We'll probably want to categorize these things based on what sort of function they perform, so we could have [[:category:character generation functions]], [[:category:event functions]], and so forth. Seems likely to me that this is how they'll usually be referenced, a builder will have a particular task he wants to do and will want to see what functions are relevant to it. I'll mock up a nonfunctional version of the template today since I've already got a good start on the parameters we'll need up above, and solicit some more input from scripters on the beta forum to make sure I'm not overlooking anything basic. [[User:BryanDerksen\|BryanDerksen]] 15:14, 21 July 2009 (UTC)
		+
		+	:::: I've added an alternative version of the mock up on my [[User_talk:Sunjammer\|Discussion]] page. Let me know what you think.
		+	:::: --[[User:Sunjammer\|Sunjammer]] 21:17, 21 July 2009 (UTC)

← Older revision		Revision as of 17:59, 21 July 2009
Line 1:		Line 1:
		+	== Function article conventions ==
		+
	At some point I'll certainly dive in to the whole wiki but my primary concern right now is generating the pages for the scripting section. I have an application (the same one I used to produce the [http://www.sunjammer.co.uk/assets/misc/dascript.zip dascript.php] GeSHi configuration file) which would be capable of mass producing the pages for each native function and helping to produce the pages for the constant groups which can then all be loaded into the wiki ''en masse''. In order to do this though we (as a group) need to decide on the naming conventions (i.e. do we add a prefix, suffix, nothing) and the basic layout of the page. I would also like to avoid putting example scripts directly on the page and instead transclude them from a "script library" section. That way if we need to/want to correct an example we only need to do it once.		At some point I'll certainly dive in to the whole wiki but my primary concern right now is generating the pages for the scripting section. I have an application (the same one I used to produce the [http://www.sunjammer.co.uk/assets/misc/dascript.zip dascript.php] GeSHi configuration file) which would be capable of mass producing the pages for each native function and helping to produce the pages for the constant groups which can then all be loaded into the wiki ''en masse''. In order to do this though we (as a group) need to decide on the naming conventions (i.e. do we add a prefix, suffix, nothing) and the basic layout of the page. I would also like to avoid putting example scripts directly on the page and instead transclude them from a "script library" section. That way if we need to/want to correct an example we only need to do it once.
	--[[User:Sunjammer\|Sunjammer]] 00:31, 21 July 2009 (UTC)		--[[User:Sunjammer\|Sunjammer]] 00:31, 21 July 2009 (UTC)

← Older revision		Revision as of 15:14, 21 July 2009
Line 56:		Line 56:

	:: --[[User:Sunjammer\|Sunjammer]] 11:46, 21 July 2009 (UTC)		:: --[[User:Sunjammer\|Sunjammer]] 11:46, 21 July 2009 (UTC)
		+
		+	::: Yeah, I wouldn't want to put 600 articles under one category anyway :) (except for purely housekeeping reasons, perhaps). We'll probably want to categorize these things based on what sort of function they perform, so we could have [[:category:character generation functions]], [[:category:event functions]], and so forth. Seems likely to me that this is how they'll usually be referenced, a builder will have a particular task he wants to do and will want to see what functions are relevant to it. I'll mock up a nonfunctional version of the template today since I've already got a good start on the parameters we'll need up above, and solicit some more input from scripters on the beta forum to make sure I'm not overlooking anything basic. [[User:BryanDerksen\|BryanDerksen]] 15:14, 21 July 2009 (UTC)