User:Tschmitz - Revision history

Egallager: link cleanup

2023-04-24T18:29:58Z

link cleanup

Egallager: fix heading levels

2023-04-24T18:26:20Z

fix heading levels

Show changes

Tschmitz: More progress (input from crab_ and anonymissimus)

2011-07-10T20:26:14Z

More progress (input from crab_ and anonymissimus)

Tschmitz: Dialogue with hopman-

2011-07-08T07:10:09Z

Dialogue with hopman-

Tschmitz: More progress

2011-06-19T19:17:05Z

More progress

Tschmitz: added Progress section

2011-06-18T20:54:36Z

added Progress section

Tschmitz: Fixed some link names

2011-04-10T21:54:58Z

Fixed some link names

Tschmitz: Added IRC times

2011-04-09T22:09:17Z

Added IRC times

Tschmitz: fixed link

2011-04-09T21:45:53Z

fixed link

Tschmitz: Some priorities changed

2011-04-09T05:09:45Z

Some priorities changed

Show changes

@@ Line 1: / Line 1: @@
 {{SoC2011Student_2|tschmitz|SoC_Ideas_Whiteboard_2011}}
 ==Description==
 <h4>Tommy Schmitz - Whiteboard Improvements</h4>
@@ Line 12: / Line 11: @@
 ==Introduction==
-This is a continuation of [http://wiki.wesnoth.org/User:Gabba gabba]'s [http://wiki.wesnoth.org/GSoC-WesnothWhiteboard_Gabba 2010 whiteboard project]! To see some of his ideas for the future of the project, see his [http://wiki.wesnoth.org/GSoC-WW_Optional_Future_Gabba "Future" page].
+This is a continuation of [[User:Gabba|gabba]]'s [[GSoC-WesnothWhiteboard_Gabba|2010 whiteboard project]]! To see some of his ideas for the future of the project, see his [[GSoC-WW_Optional_Future_Gabba|"Future" page]].
 After compiling a list of several sub-tasks, I can now describe my project as a plan to turn the whiteboard into a powerful "what-if scenario" engine and planning system. I plan to add network support to enable players to plan with their allies on the network, and after that, I plan to make it possible to consider possible actions by enemies and suggest possible actions to allies. As a kind of perk that is worth mentioning here, I hope to upgrade the damage calculations dialog to be able to take into account multiple attacks against the same target (either against an enemy target or against one of your own units).
 The details section below covers the following sub-tasks
-* [http://wiki.wesnoth.org/User:Tschmitz#.22Suppose_dead.22_planning "Suppose dead" planning]
+* [[User:Tschmitz#.22Suppose_dead.22_planning|"Suppose dead" planning]]
-* [http://wiki.wesnoth.org/User:Tschmitz#Change_behavior_of_invalid_actions Change behavior of invalid actions]
+* [[User:Tschmitz#Change_behavior_of_invalid_actions|Change behavior of invalid actions]]
-* [http://wiki.wesnoth.org/User:Tschmitz#Network_support Network support]
+* [[User:Tschmitz#Network_support|Network support]]
-* [http://wiki.wesnoth.org/User:Tschmitz#Multi-turn_moves Multi-turn moves]
+* [[User:Tschmitz#Multi-turn_moves|Multi-turn moves]]
-* [http://wiki.wesnoth.org/User:Tschmitz#.28optional.29_Suggesting_planned_actions_to_allies (optional) Suggesting planned actions to allies]
+* [[User:Tschmitz#.28optional.29_Suggesting_planned_actions_to_allies|(optional) Suggesting planned actions to allies]]
-* [http://wiki.wesnoth.org/User:Tschmitz#.28optional.29_.22What-if.22_enemy_actions (optional) "What-if" enemy actions]
+* [[User:Tschmitz#.28optional.29_.22What-if.22_enemy_actions|(optional) "What-if" enemy actions]]
-* [http://wiki.wesnoth.org/User:Tschmitz#.28optional.29_Cumulative_combat_probability_calculations (optional) Cumulative combat probability calculations]
+* [[User:Tschmitz#.28optional.29_Cumulative_combat_probability_calculations|(optional) Cumulative combat probability calculations]]
-* [http://wiki.wesnoth.org/User:Tschmitz#.28optional.29_Interface_updates (optional) Interface updates]
+* [[User:Tschmitz#.28optional.29_Interface_updates|(optional) Interface updates]]
 ==Details==
@@ Line 53: / Line 52: @@
 ===Network support===
 =====Motivation=====
-This was the original purpose of the whiteboard! See [http://wiki.wesnoth.org/GSoC-WesnothWhiteboard_Gabba#A_little_use_case gabba's page] for some motivation.
+This was the original purpose of the whiteboard! See [[GSoC-WesnothWhiteboard_Gabba#A_little_use_case|gabba's page]] for some motivation.
 =====Proposed Solution=====
 Teams of allies will essentially share a whiteboard, as far as they'll be able to tell (though the implementation underneath will tell a slightly different story, since their action_queues will be separate). They'll only be able to plan actions for their own units, though.
@@ Line 61: / Line 60: @@
 The future_unit_map is currently constructed by applying the actions from the current side's action_queue only. Instead, it must also apply the action_queues of every ally afterward, in the order that their turns will be taken. This data will need to be serialized and unserialized. Finally, the whiteboard data will piggyback on the turn_info that gets sent through the network. Additional sending/receiving code will be necessary to send data across the network on every modification, not just non-undoable actions.
-For more information, see [http://wiki.wesnoth.org/GSoC-WesnothWhiteboard_Gabba#Engine gabba's original ideas] on this part of the project.
+For more information, see [[GSoC-WesnothWhiteboard_Gabba#Engine|gabba's original ideas]] on this part of the project.
 =====Open Questions=====
 * Should the data be serialized into config form or raw-data form?

@@ Line 199: / Line 199: @@
 ====Dialogue with hopman-====
- [22:33] <hopman-> tschmitz: Not sure how much I can help you
+* [22:33] <hopman-> tschmitz: Not sure how much I can help you
- [22:34] <hopman-> tschmitz: If I remember correctly, underlying_id() should be unique for each real unit and should be the same for the life of that unit (at least in a single scenario).
+* [22:34] <hopman-> tschmitz: If I remember correctly, underlying_id() should be unique for each real unit and should be the same for the life of that unit (at least in a single scenario).
- [22:35] <hopman-> tschmitz: the unit_map still has code that will reassign an id if it sees multiple of a single id, but I don't think that that is actually possible
+* [22:35] <hopman-> tschmitz: the unit_map still has code that will reassign an id if it sees multiple of a single id, but I don't think that that is actually possible
- [22:36] <tschmitz> hopman-: How about being the same for all clients in a multiplayer game?
+* [22:36] <tschmitz> hopman-: How about being the same for all clients in a multiplayer game?
- [22:36] <tschmitz> hopman-: It seemed to me that "sometimes" the underlying_id counter would get reset between playing games, and "sometimes" not
+* [22:36] <tschmitz> hopman-: It seemed to me that "sometimes" the underlying_id counter would get reset between playing games, and "sometimes" not
- [22:36] <hopman-> I think it is synced, but I am not sure... I know it used to be not synced, but I thought that was changed
+* [22:36] <hopman-> I think it is synced, but I am not sure... I know it used to be not synced, but I thought that was changed
- [22:36] <hopman-> yeah, I'm not sure
+* [22:36] <hopman-> yeah, I'm not sure
- [22:36] <tschmitz> hopman-: OK
+* [22:36] <tschmitz> hopman-: OK
- [22:37] <tschmitz> Thanks for the help
+* [22:37] <tschmitz> Thanks for the help
- [22:37] <tschmitz> Did you read about what I'm using it for?
+* [22:37] <tschmitz> Did you read about what I'm using it for?
- [22:37] <hopman-> I know that when I had been working on that area, I had wanted it to be synced across clients, but I don't know if that ever happened
+* [22:37] <hopman-> I know that when I had been working on that area, I had wanted it to be synced across clients, but I don't know if that ever happened
- [22:37] <hopman-> No, I didn't see that.
+* [22:37] <hopman-> No, I didn't see that.
- [22:38] <tschmitz> hopman-: Yeah basically I'm trying to serialize "the identity" of a unit for transport across the network
+* [22:38] <tschmitz> hopman-: Yeah basically I'm trying to serialize "the identity" of a unit for transport across the network
- [22:38] <tschmitz> hopman-: whiteboard objects contain references to the units for whom plans are made
+* [22:38] <tschmitz> hopman-: whiteboard objects contain references to the units for whom plans are made
- [22:38] <tschmitz> hopman-: and now I'm sending whiteboard objects over the network, so
+* [22:38] <tschmitz> hopman-: and now I'm sending whiteboard objects over the network, so
- [22:40] <tschmitz> hopman-: Can you answer me whether it's guaranteed that saving a game and loading it again will preserve the underlying_id of all the units?
+* [22:40] <tschmitz> hopman-: Can you answer me whether it's guaranteed that saving a game and loading it again will preserve the underlying_id of all the units?
- [22:40] <tschmitz> hopman-: and keep the "next-underlying_id" the same also
+* [22:40] <tschmitz> hopman-: and keep the "next-underlying_id" the same also
- [22:41] <hopman-> tschmitz: No, I cannot say for sure.
+* [22:41] <hopman-> tschmitz: No, I cannot say for sure.
- [22:42] <tschmitz> hopman-: That's all right; do you think there exists a person who knows?
+* [22:42] <tschmitz> hopman-: That's all right; do you think there exists a person who knows?
- [22:42] <tschmitz> hopman-: or perhaps a document?
+* [22:42] <tschmitz> hopman-: or perhaps a document?
- [22:47] <hopman-> tschmitz: No, I can't really help with that.
+* [22:47] <hopman-> tschmitz: No, I can't really help with that.
- [22:47] <tschmitz> hopman-: All-righty, well thanks for the input.
+* [22:47] <tschmitz> hopman-: All-righty, well thanks for the input.

← Older revision		Revision as of 07:10, 8 July 2011
Line 197:		Line 197:
	#**** action::from_config()		#**** action::from_config()
	# Voila! Whiteboard action has been transmitted		# Voila! Whiteboard action has been transmitted
		+
		+	====Dialogue with hopman-====
		+	[22:33] <hopman-> tschmitz: Not sure how much I can help you
		+	[22:34] <hopman-> tschmitz: If I remember correctly, underlying_id() should be unique for each real unit and should be the same for the life of that unit (at least in a single scenario).
		+	[22:35] <hopman-> tschmitz: the unit_map still has code that will reassign an id if it sees multiple of a single id, but I don't think that that is actually possible
		+	[22:36] <tschmitz> hopman-: How about being the same for all clients in a multiplayer game?
		+	[22:36] <tschmitz> hopman-: It seemed to me that "sometimes" the underlying_id counter would get reset between playing games, and "sometimes" not
		+	[22:36] <hopman-> I think it is synced, but I am not sure... I know it used to be not synced, but I thought that was changed
		+	[22:36] <hopman-> yeah, I'm not sure
		+	[22:36] <tschmitz> hopman-: OK
		+	[22:37] <tschmitz> Thanks for the help
		+	[22:37] <tschmitz> Did you read about what I'm using it for?
		+	[22:37] <hopman-> I know that when I had been working on that area, I had wanted it to be synced across clients, but I don't know if that ever happened
		+	[22:37] <hopman-> No, I didn't see that.
		+	[22:38] <tschmitz> hopman-: Yeah basically I'm trying to serialize "the identity" of a unit for transport across the network
		+	[22:38] <tschmitz> hopman-: whiteboard objects contain references to the units for whom plans are made
		+	[22:38] <tschmitz> hopman-: and now I'm sending whiteboard objects over the network, so
		+	[22:40] <tschmitz> hopman-: Can you answer me whether it's guaranteed that saving a game and loading it again will preserve the underlying_id of all the units?
		+	[22:40] <tschmitz> hopman-: and keep the "next-underlying_id" the same also
		+	[22:41] <hopman-> tschmitz: No, I cannot say for sure.
		+	[22:42] <tschmitz> hopman-: That's all right; do you think there exists a person who knows?
		+	[22:42] <tschmitz> hopman-: or perhaps a document?
		+	[22:47] <hopman-> tschmitz: No, I can't really help with that.
		+	[22:47] <tschmitz> hopman-: All-righty, well thanks for the input.

← Older revision		Revision as of 19:17, 19 June 2011
Line 181:		Line 181:
	* Add calls to side_actions::execute_network_command() inside turn_info::process_network_data()		* Add calls to side_actions::execute_network_command() inside turn_info::process_network_data()
	* Add call to <something>::send_to_allies() and to to_config() inside side_actions mutator functions		* Add call to <something>::send_to_allies() and to to_config() inside side_actions mutator functions
		+
		+	====Network sequence====
		+	# User adds something to whiteboard
		+	#* side_actions::insert_action()
		+	#** temp = side_actions::make_net_cmd_insert()
		+	#*** action::to_config()
		+	#** manager::queue_net_cmd(temp)
		+	# The time comes for replay info to be sent out
		+	#* replay_network_sender::sync_non_undoable() or replay_network_sender::commit_and_sync
		+	#** manager::inject_wb_data()
		+	# Other players receive packet (including enemies, but they just discard the packet ... vulnerable to cheaters)
		+	#* turn_info::process_network_data()
		+	#** manager::process_network_data()
		+	#*** side_actions::execute_net_cmd()
		+	#**** action::from_config()
		+	# Voila! Whiteboard action has been transmitted

← Older revision		Revision as of 20:54, 18 June 2011
Line 150:		Line 150:

	When Player 1 makes a planned action, it goes into the main Player 1 action_queue, is sent to all allies through the network, and is placed into their local Player 1 action_queues. When Player 1 suggests an action to Player 2, it goes into the action_queue for "suggestions from Player 1 to Player 2," is sent to all allies through the network, and is placed into their local action_queues for "suggestions from Player 1 to Player 2." When Player 2 wants to see a what-if scenario for units controlled by (Enemy) Player 3, the action is placed into Player 1's local action_queue for (Enemy) Player 3, is sent to all allies through the network, and is placed into their local action_queues for (Enemy) Player 3 (this causes an issue with simultaneous modification, so this may change; perhaps there will be a separate action_queue for "What-if scenarios by Player 1 about Player 3" so that the only one modifying that list is Player 1).		When Player 1 makes a planned action, it goes into the main Player 1 action_queue, is sent to all allies through the network, and is placed into their local Player 1 action_queues. When Player 1 suggests an action to Player 2, it goes into the action_queue for "suggestions from Player 1 to Player 2," is sent to all allies through the network, and is placed into their local action_queues for "suggestions from Player 1 to Player 2." When Player 2 wants to see a what-if scenario for units controlled by (Enemy) Player 3, the action is placed into Player 1's local action_queue for (Enemy) Player 3, is sent to all allies through the network, and is placed into their local action_queues for (Enemy) Player 3 (this causes an issue with simultaneous modification, so this may change; perhaps there will be a separate action_queue for "What-if scenarios by Player 1 about Player 3" so that the only one modifying that list is Player 1).
		+
		+
		+
		+	=Progress=
		+	protocol for whiteboard config "packets"
		+	[whiteboard]
		+	command=insert
		+	index=4
		+	[action]
		+	...
		+	[/action]
		+	[/whiteboard]
		+	or
		+	[whiteboard]
		+	command=remove
		+	index=4
		+	[/whiteboard]
		+	etc.
		+
		+	17 June 2011
		+	* Add "config to_config() const" to each subclass of wb::action
		+	* Add "static action_ptr from_config(config)" to wb::action itself
		+	18 June 2011
		+	* Add "static void send_to_allies(config)" somewhere (maybe wb::manager)
		+	** This function calls network::send_data()
		+	** Is there a function that does this already? Ask.
		+	* Add "void execute_network_command(net_command)" to wb::side_actions
		+	** Add "typedef config net_command" to wb::side_actions
		+	** This function calls wb::action::from_config()
		+	* Add calls to side_actions::execute_network_command() inside turn_info::process_network_data()
		+	* Add call to <something>::send_to_allies() and to to_config() inside side_actions mutator functions

@@ Line 254: / Line 254: @@
 <b>1.5) What are you studying, subject, level and school?</b> I am working toward a bachelor's degree in computer science and mathematics.
-<b>1.6) What country are you from, at what time are you most likely to be able to join IRC?</b> I'm from the United States and I have already joined IRC.
+<b>1.6) What country are you from, at what time are you most likely to be able to join IRC?</b> I'm from the United States. My local time is currently UTC - 7. During the week, I should be on IRC with roughly the following schedule (times given in UTC):
 <b>1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.</b> I will be in school until June 9, so my time will be somewhat limited until this day. Aside from that, my intent for the summer is to take on this project exclusively; I have planned no vacations.

← Older revision		Revision as of 21:45, 9 April 2011
Line 9:		Line 9:

	=Submitted Patch=		=Submitted Patch=
−	* [https://gna.org/patch/?2622, Fixed some whiteboard bugs]	+	* [https://gna.org/patch/?2622 Fixed some whiteboard bugs]