[Wesnoth-bugs] [bug #21768] segfault in lua_function= filter

[Anonymissimus]

Follow-up Comment #1, bug #21768 (project wesnoth):

There's nothing attached, you forgot the savefile.

However, do note that lua_function= was sort of unstable from the start, is
supposed to be used with care and the usual rule "wml/lua should never crash
wesnoth" doesn't apply.
For instance, if the code put into the called lua_function happens to remove
or add units from the unit_map, this could end up very badly, since the SUF
itself, where the funtion appears, iterates over the unit_map. So that's
deleting or adding elements from a container while iterating over it, but not
updating the iterator after the modification. It seems you are doing exactly
this. If so, then, well, it's misusage of lua_function=, which should not be
used to alter the gamestate in any way; it should only compute a boolean
return value.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21800] a side with controller=null is shown in the game lobby

[SlowThinker]

URL:
  

 Summary: a side with controller=null is shown in the game
lobby
 Project: Battle for Wesnoth
Submitted by: slowthinker
Submitted on: Sat Mar 15 17:19:21 2014
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Multiplayer Lobby
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.11.11
Operating System: Windows XP

___

Details:

Wesnoth 1.10 didn't show such a side in the list of sides.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21768] segfault in lua_function= filter

[Anonymissimus]

Follow-up Comment #2, bug #21768 (project wesnoth):

Reading the other bug report hardens my assumption.
You can perhaps get around the problem by not using any of those lua functions
which add or remove units from the unit_map (wesnoth.put_unit,
wesnoth.extract_unit). wesnoth.get_unit(s) return you direct "pointers" to the
unit objects in the unit_map, which cou can modify (you modify only the
entries of the container, not the container itself then). You can't use the
.__cfg field then however.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21697] MP synchronization not tracked well, creates minefield for add-on designers

[Daniel]

Update of bug #21697 (project wesnoth):

 Assigned to:None => gfgtdf2

___

Follow-up Comment #5:




___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21158] "gamemap" class doesn't handle empty files

[Anonymissimus]

Follow-up Comment #2, bug #21158 (project wesnoth):

>This seems to be introduced by rev
52641/d75e320e5aa4b801cb9d0f4ef6722e1d4f37635a

I don't think so. It should already have happened before that; the default I
added (allow_invalid = true) just matches the previous behavior. I was working
on the [replace_map] and [terrain_mask] callstacks only when fixing
https://gna.org/bugs/?19018 and didn't consider the "mp create game"
callstack, perhaps an invalid map should be disallowed as well or  never be
allowed. Then gamemap::read would likely throw the incorrect_map_format_error
after catching a t_translation::error.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21158] "gamemap" class doesn't handle empty files

[Anonymissimus]

Update of bug #21158 (project wesnoth):

 Assigned to:   anonymissimus => None   


___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21768] segfault in lua_function= filter

[Eli Dupree]

Follow-up Comment #3, bug #21768 (project wesnoth):

Uploaded the file.

I agree that the behavior I'm using shouldn't be supported. However, my
understanding is that Wesnoth should *never* be exposing unsafe pointers to
scripts, because it is a security issue. The proper behavior would be to
prevent scripts from using state-mutating functions during filters, and emit a
warning.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21797] Saving and loading in multiplayer creates side with no controller

[Chris Beck]

Follow-up Comment #1, bug #21797 (project wesnoth):

I never knew this, but apparently there is a unit "Nani the Shapeshifter"
submerged in the upper left corner of this map.

https://github.com/wesnoth/wesnoth/blob/master/data/multiplayer/scenarios/2p_Silverhead_Crossing.cfg#L36

>From inspecting your save file, side 3 gets saved with controller
type="network" by client B. That is not a bug. When the AI is controlled by
another client, the controller type is listed as "network".

This might have something to do with the refactor of the mp_connect_dialog? It
might be that the fields "hidden=yes" / "allow_player = no" are causing it to
ignore this side and not set it to an AI.

In fact I find that if you change the value of "allow_player" to yes in the
save file, then you can load the game correctly without problems. The only
issue is, now you have to assign a controller to side 3 in the dialog. So I
think there's a logic error somewhere in either the dialog or the
mp_game_utils function that builds the WML at the start of an mp scenario.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21801] entering "Create Game" is slow

[SlowThinker]

URL:
  

 Summary: entering "Create Game" is slow
 Project: Battle for Wesnoth
Submitted by: slowthinker
Submitted on: Sat Mar 15 23:46:15 2014
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Multiplayer Lobby
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.11.11
Operating System: Windows XP

___

Details:

Entering the window "Create Game" is very slow, regardless where one enters it
from:
It happens even if a player is in the window "Configure Game" already, and he
presses "Back".





___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21800] a side with controller=null is shown in the game lobby

[SlowThinker]

Follow-up Comment #1, bug #21800 (project wesnoth):

Now I noticed allow_player= should control whether the side is shown in the
game lobby. 
(In Wesnoth 1.10 controller=null prevents the side is shown too, for some
reason unknown to me)

Anyway in Wesnoth 1.11 allow_player=no is ignored.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21797] Saving and loading in multiplayer creates side with no controller

[Chris Beck]

Follow-up Comment #2, bug #21797 (project wesnoth):

involution wrote: "That is not a bug."

Actually I guess no one is sure, but if it is a bug it is a duplicate of
https://gna.org/bugs/?18829

I find that when I modify your savefile so that the controller type is
"network_ai" then everything works.

So there's two issues to fix here, either of which would resolve this
particular issue (but ideally we would fix both):

1. Make the mp_game_utils.cpp initial level config function be sure to always
set controller type to AI if allow_player = no.

2. Fix bug https://gna.org/bugs/?18829

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #21800] a side with controller=null is shown in the game lobby

[Chris Beck]

Follow-up Comment #2, bug #21800 (project wesnoth):

"Anyway in Wesnoth 1.11 allow_player=no is ignored."

>From tests I was just doing on this other bug, I don't think that this is
ignored.

https://gna.org/bugs/index.php?21797

And it appears in the source code that this is indeed the only variable that
controlelrs whether it is shown.

https://github.com/wesnoth/wesnoth/blob/master/src/multiplayer_connect.cpp#L421

Currently "controller=null" will just make the side be assigned "empty" by
default, afaik.

https://github.com/wesnoth/wesnoth/blob/master/src/multiplayer_connect_engine.cpp#L868

Are you sure that this isn't working? Can you provide a test file?

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs