Hmm, that is interesting: I wonder if the root cause of the "money bag spam" exploit can be fixed in your module system code, or whether it is an unfixable problem due to how certain operations happen in the engine. I remembered a change I did years ago to restrict how often players can drop money bags, seems to be one every 5 seconds, so does that code not work any more, or by "spam money bag" do you mean something other than quickly drop heaps of money bags? Is it just simply retrying the money bag drop and bank transfer as close as possible to the same time over and over, until the exploit happens? Do you know if the same method can be used with other PW props, such as to buy weapons at the same time as dropping money bags, or does it seem to be peculiar to unofficial banking scripts?domipoppe said:Well for me my scripts temporarily remove the gold of the player before the send_message_to_url and then as soon as response comes it either:
- Give the player the gold back (if the bank is full for example)
- or finally, remove it and reset the temp slot (if the deposit was valid).
That's how I do it and this is glitchable with this spam money bag as well which makes, in my opinion, no sense cause before I send a message I temp remove the gold already.
You can press F1 while in that mode to display another information window detailing other function keys, and some general PW scene editing information. There is also a more detailed guide with other information in the sticky thread: I have just added the in game information as a section to that post, since it doesn't change often along with new releases anymore.The values can be modified in the scene editor panel, scene prop section: the two fields, labelled 'Var No' and 'Var 2 No'. These can each store an integer in the range 0 - 127.
The scene props with 'value 1 = faction + multiplier' share the same code for storing a combination of faction id / castle id and gold value multiplier in value 1:
0 is the commoner faction, which normally means the prop is not associated with any faction, 1 for outlaws, and 2 - 9 associate the scene prop with a castle (which starts owned by the corresponding faction id).
The other part is a multiple of 10, representing specific gold value multipliers:
0 = 100%, the default value
10 = 20%
20 = 40%
30 = 60%
40 = 80%
50 = 120%
60 = 140%
70 = 160%
80 = 180%
90 = 200%
100 = 350%
110 = 500%
120 = 1000%
These two separate values are combined: for example, 31 = outlaw faction and 60% value, 116 = castle 5 (starts owned by faction 5, the yellow faction) and 500% value.
You can make some glitches work by modifying client side code (generally things like wall hacks or unlimited distance name labels, which are just revealing things the client knows but hides from the player), but most should be prevented in server code: messages received by the server from a client should be mistrusted wherever possible. For example, the standard PW code for transferring money from a castle money chest has the client side check for the distance to the chest, whether there is enough money in the chest, then sends the player id, chest instance id, and money to transfer; the server side receives those values and does all the checks again and more, so the distance to the chest is checked again, the money in the chest, also whether the player is in the right faction, has keys, or the chest is broken, and then only if all the checks pass on the server is the money actually transferred and the clients updated. You might notice that the same script cf_use_castle_money_chest is run on both the clients and the server, with some code being run on both, and other bits split up: I designed various scripts this way to share code, and they should be labeled at the first line comment whether server, client, or both.domipoppe said:Scripters can locally modify the module (same for PW) and make such glitches easily work again.
Like call server messages clientside etc. This stuff needs to be secured and whilst releasing at as OSP it is hard to secure cause everyone can read the full code.
You see it by the NW troll bettygta etc.
If you are trying to change player equipment while they are spawned into the scene, you need to change the agent's equipment, not the player's: the player object is created when they join the server, and remains to store related data until they disconnect, but the agent object is created only when the visible character is spawned, and is destroyed soon after the character dies (about 30 seconds). To change what the player will have instantly, you need to use the agent_equip_item and agent_unequip_item operations: note that the optional third parameter to the operations (slot number) when equipping weapon items uses different values to the ek_item_* constants noted above, slots 1 - 4 rather than 0 - 3; and armor items are automatically put in the correct slot, but only the stats for combat calculations on the server is updated automatically, so you need to manually send messages to all connected clients to run agent_equip_item to update the visible armor mesh. From memory, I think that if an agent equip slot already has a weapon in it, trying to equip another one on top might do nothing, so you have to unequip it first to replace it.alkaiq said:I just started modding and I have been trying to figure out how to find out the correct <slot_no> of multiplayer players' equipement.
E.g. we all have 4 inventory slots for melee/ranged items. How do I know what is the <slot_no> of a particular item (for example, the most top slot)?
(store_random_in_range, ":adjust_fish", -2, 4), (val_add, ":fish_count", ":adjust_fish"), (val_max, ":fish_count", 0),
It seems like you might be trying to use Python 3 to build M&B, which doesn't work (I seem to remember the error when doing that to test): ensure that the debian package for Python 2.7 is installed, and try calling that binary specifically (might be called python2.7 or something). Python on Linux has always worked perfectly fine to build M&B, since I have done that for years.Fearg said:It produces this for each process_X.py that deals with module_troops.py (so its just the same syntax error over and over)File "/home/usr/Documents/Viking Conquest2/process_operations.py", line 14, in <module>
from module_troops import *
File "/home/usr/Documents/Viking Conquest2/module_troops.py", line 4184
SyntaxError: invalid syntax
Not without changing the scripts in ways that could break compatibility with official PW clients. For your event, what would stop every player using the same best tier equipment, every time they spawn? You could either use no_money and set the scene up with the appropriate starting equipment in stockpiles, forcing the players to maintain or produce the equipment, or you could use quick_battle and give each player some large amount of money to use - setting everyone to have a ridiculous amount of money when first joining would probably be the simplest tweak to work around the design (up to max_possible_gold = 1000000000 - 1). To do that, search for "# otherwise, set default attributes" in script setup_player_joined, and add a line like (assign, ":gold_value", max_possible_gold - 1) after the (assign, "utlaw_rating", 0) line, and build it for the server (presuming you are not using a modded scripts.txt without the module_scripts.py source).Anani said:Is having both no_money and quick_battle possible?
Only 100 is possible with the standard client, but 400 or whatever amount can be enabled if you tweak your client to raise the limit in the administrator panel presentation, like this:Anani said:Is there any way I can set 200, or 400 bots?
diff --git a/module_presentations.py b/module_presentations.py index 3ec82ed..89c77b3 100644 --- a/module_presentations.py +++ b/module_presentations.py @@ -786,7 +786,7 @@ presentations.extend([ (position_set_y, pos1, ":cur_y"), (overlay_set_position, reg0, pos1), - (create_number_box_overlay, "$g_presentation_obj_admin_panel_bot_count", 0, 101), + (create_number_box_overlay, "$g_presentation_obj_admin_panel_bot_count", 0, 501), (position_set_x, pos1, 390), (position_set_y, pos1, ":cur_y"), (overlay_set_position, "$g_presentation_obj_admin_panel_bot_count", pos1),
The command is "set_bot_count 200 0" (must specify team 0), but it didn't work for me (not sure why, don't have time to troubleshoot): setting it in the administrator panel works.Anani said:should something like ''set_bots 200'' do the trick?
Baskakov_Dima said:Well, now if you make a patch with those animations it would hardly be considered "much".
Baskakov_Dima said:Those animations don't really change balance, they mainly change how the game looks like.
That is not correct: the animations are used for the combat calculations and timings. So if a patch was made that was applied only to the server or some clients, everyone not using the animation set used on the server would be at a disadvantage, not seeing the actual combat calculations going on, and maybe get frustrated by other players seeming to cheat. Using the other animations would almost certainly change the balance between different weapons or weapon types: for example, the two handed swing animation might have less reach, or the polearm thrust animation might be quicker. This is the reason I decided not to use the animations from the start: even though they look better, I didn't want the distraction of trying to figure out how to rebalance things to suit, when the mod is not solely combat focused.Baskakov_Dima said:Overall, the animations by Papa Lazarou just look a lot better, that's it. It's not even a "major" change.
PW was in early development around the time Papa Lazarou was developing his "combat animation enhancement" mod, and I agreed in principle with some of his ideas and changes, but after trying them out and weighing up both options, I elected not to integrate those combat animations with PW: the main reason being that I didn't want to get bogged down with changing too much at once. I had been involved in testing and discussion during the Warband beta period before full public release, and wanted to concentrate on making a different game mode mostly keeping the Native Warband setting and combat balance; to make the mod more quickly playable, and concentrate the development and discussion on the main features of the mod, rather than try recreate everything from scratch.Baskakov_Dima said:Hello. I am pretty sure it was suggested before, though I didn't find the post. Vanilla animations are very ugly. Yes, they are easily readable, but any video of people mass fighting, feinting etc. using those animations would look dumb.
Have you thought of installing alternative animations, so roleplay looks better? I know that it's possible to make a mini-mod by copying those animations on both the server and client, yes, but I thought that it would be interesting if they would be included in the standard package.
PW uses a bunch of hacks related to player and agent teams to work around the hard coded multiplayer limit of two, which has implications for bots (which the mod was not designed for). See these threads in the PW modding board:Ramaraunt said:Im making zombies for a pw mod, but they attack each other. How do you fix this so they are friendly to each other? I tried:
Those operations have no position register parameter, and I think unset parameters are recognised as 0 (pos0).domipoppe said:Code:
(position_get_x, ":pos_x"), (position_get_y, ":pos_y"),
Most of the editing values for pw_ prefixed scene props are explained in the information window accessible by pressing F2 when in the "edit a scene" game mode, but before pressing control-e to actually edit it (still walking around the scene as a test character). From that information window, also accessible from module_strings.py in the module system (if you don't want to start the game):cj4884305 said:（pw-scene-light)How does this light change his color
The flicker magnitude and flicker interval are passed directly on to the add_point_light_to_entity module system operation, which has this comment:header_strings.py said:value 1 = flicker magnitude
value 2 = flicker interval
scale x = red, 1.00 = 100
scale y = green, 1.00 = 100
scale z = blue, 1.00 = 100
The scale x y and z can be modified in the scene editing properties window, or by using using the shortcut keys and mouse to adjust the scale, to mix the desired colour with RGB values.header_operations.py said:flicker_magnitude between 0 and 100, flicker_interval is in 1/100 seconds
It sounds like you have the 4.5.0 module version on your server, not 4.5.1: there was a bug found and fixed soon after the 4.5 release, that only affected servers and didn't warrant a major version bump.Serrallonga said:I have mounted a server with server status and server_name and everything works perfectly, but when I try to change a permission from the servername panel, the fields are marked gray but no effect on the server. I can block names by id, store session statistics but I can not change permissions.
Vornne said:I have also found the bug that caused admin permissions from the name server not to be applied, in the game_receive_url_response module script: the fixed module has been uploaded as PW_4.5.1 for the full download and the patch, but only server hosters will have any difference and should update their dedicated server module (the name is still PW_4.5, and 4.5.0 clients are still fully compatible). The name server was also updated with some bug fixes, so it should be downloaded again (see the diffs on github for details).
That patch comes in two parts: the first is the LOD mesh resources, which basically never change, and the second is for the module.ini to load the meshes, which changes nearly every version. Apply both, and it should work.The_Ass_Man said:failed to load: resource/lod_armors_b.brf
Vornne said:Patch adding LOD meshes for some small objects and interiors: this might cause a small FPS increase. This file should stay current for any later versions, so you might want to keep it for extracting into later PW releases; it also requires the following patch to enable it:
Patch enabling the LOD meshes in PW_4.5.0: this must be used in conjunction with the above patch; updated for 4.5.0.