Element Data - Revision history

Winky-: Redirected page to Element data

2011-11-17T18:05:30Z

Redirected page to Element data

← Older revision		Revision as of 18:05, 17 November 2011
Line 1:		Line 1:
	~~{{Outdated\|This is an outdated proposal page. Information about the element data system can be found in~~ [[Element data]]~~.}}~~		#redirect [[Element data]]

	Elements currently can store arbitrary data values. It is proposed that these values are also read from the XML map file's attributes, when the map is loaded. This would have the impact that XML event handlers would be also become element data values, but somewhat confusingly to users, editing this data would not change the actual code. It may be advisable that event handlers are loaded from this element data, rather than from the raw XML data. This would in theory allow self-writing code, for example, you could use [[setElementData]] to write some code, then call addEvent to add an event of that name. Perhaps it would be useful to make it so that element data is tied to events, so that if you change the element data for an event, the code is reloaded into the VM and overwrites the existing (hidden) function. This would probably be relatively trivial to implement.

Winky-: Template outdated added

2011-11-11T15:47:25Z

Template outdated added

← Older revision		Revision as of 15:47, 11 November 2011
Line 1:		Line 1:
	~~''Note: this~~ is an outdated proposal page. Information about the element data system can be found in [[Element data]].''		{{Outdated\|This is an outdated proposal page. Information about the element data system can be found in [[Element data]].}}

	Elements currently can store arbitrary data values. It is proposed that these values are also read from the XML map file's attributes, when the map is loaded. This would have the impact that XML event handlers would be also become element data values, but somewhat confusingly to users, editing this data would not change the actual code. It may be advisable that event handlers are loaded from this element data, rather than from the raw XML data. This would in theory allow self-writing code, for example, you could use [[setElementData]] to write some code, then call addEvent to add an event of that name. Perhaps it would be useful to make it so that element data is tied to events, so that if you change the element data for an event, the code is reloaded into the VM and overwrites the existing (hidden) function. This would probably be relatively trivial to implement.		Elements currently can store arbitrary data values. It is proposed that these values are also read from the XML map file's attributes, when the map is loaded. This would have the impact that XML event handlers would be also become element data values, but somewhat confusingly to users, editing this data would not change the actual code. It may be advisable that event handlers are loaded from this element data, rather than from the raw XML data. This would in theory allow self-writing code, for example, you could use [[setElementData]] to write some code, then call addEvent to add an event of that name. Perhaps it would be useful to make it so that element data is tied to events, so that if you change the element data for an event, the code is reloaded into the VM and overwrites the existing (hidden) function. This would probably be relatively trivial to implement.

Jbeta at 18:09, 14 September 2007

2007-09-14T18:09:47Z

← Older revision		Revision as of 18:09, 14 September 2007
Line 1:		Line 1:
			''Note: this is an outdated proposal page. Information about the element data system can be found in [[Element data]].''

	Elements currently can store arbitrary data values. It is proposed that these values are also read from the XML map file's attributes, when the map is loaded. This would have the impact that XML event handlers would be also become element data values, but somewhat confusingly to users, editing this data would not change the actual code. It may be advisable that event handlers are loaded from this element data, rather than from the raw XML data. This would in theory allow self-writing code, for example, you could use [[setElementData]] to write some code, then call addEvent to add an event of that name. Perhaps it would be useful to make it so that element data is tied to events, so that if you change the element data for an event, the code is reloaded into the VM and overwrites the existing (hidden) function. This would probably be relatively trivial to implement.		Elements currently can store arbitrary data values. It is proposed that these values are also read from the XML map file's attributes, when the map is loaded. This would have the impact that XML event handlers would be also become element data values, but somewhat confusingly to users, editing this data would not change the actual code. It may be advisable that event handlers are loaded from this element data, rather than from the raw XML data. This would in theory allow self-writing code, for example, you could use [[setElementData]] to write some code, then call addEvent to add an event of that name. Perhaps it would be useful to make it so that element data is tied to events, so that if you change the element data for an event, the code is reloaded into the VM and overwrites the existing (hidden) function. This would probably be relatively trivial to implement.

EAi at 21:43, 28 April 2006

2006-04-28T21:43:02Z

New page

Elements currently can store arbitrary data values. It is proposed that these values are also read from the XML map file's attributes, when the map is loaded. This would have the impact that XML event handlers would be also become element data values, but somewhat confusingly to users, editing this data would not change the actual code. It may be advisable that event handlers are loaded from this element data, rather than from the raw XML data. This would in theory allow self-writing code, for example, you could use [[setElementData]] to write some code, then call addEvent to add an event of that name. Perhaps it would be useful to make it so that element data is tied to events, so that if you change the element data for an event, the code is reloaded into the VM and overwrites the existing (hidden) function. This would probably be relatively trivial to implement.