Search results

  1. White textures on Mac/Linux

    I know very little about shader programming or the M&B code in particular, I just disliked the "green reflections" on new Warband scene props, so tweaked those shaders very slightly to disable that aspect, and also tweaked some other shaders used for wood and stone walls to work better with dynamic point lights (mainly hand held torches), named with "greenbump" for lack of a better term, since that type of bumpmap appears green and black rather than blue and purple. These commits show the only changes from the standard Warband shaders: https://github.com/vornne/pw_module_system/commits/pw/shaders

    Unfortunately I have forgotten what I ever learned about the shader code: I was intending one day to try rewrite the whole shader file to try learn about and maybe optimise it, but never got around to that; other people on the forums have already done that sort of thing, so it would probably be "reinventing the wheel", with the sole benefit of personal learning.

    To fix the white textures on Mac and keep the same appearance as on Windows, the simplest thing would probably be to reproduce the same small tweaks compared to Native (shown in the commits linked above) in the shader source for the GLSL Mac/Linux version: I don't know if that is available, but someone else on the forums might have access to it.

    I can't reply directly to your numbered questions, since I don't know the best alternatives compatible with Mac - other than removing the _greenbump and _noterraincolor parts to use the Warband shaders they were based on, the same as the "revert to Native" patch does.
  2. Money Bank Dupe Bug Fix [Free + Source]

    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.
    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?
  3. Changing Item Prices - Castle Money Chests [?]

    From the scene prop editor values information window, opened using F2 while editing a scene using PW "Edit a Scene" mode, while walking around (before using control-e to open the editor window).
    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 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.
  4. Money Bank Dupe Bug Fix [Free + Source]

    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.
    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.

    The general principle is that script checks on the client side can be useful to run preparatory code to find things - which can be computationally expensive, avoiding load on the server where possible - and (on clients not modified to remove checks) to prevent idiots spamming buttons to flood the server with impossible request messages; then every client check before requesting something is also rechecked on the server if at all possible. On the server it is not necessary to check again for every cart that is in range of the player to attach, but the nearest cart that was found on the client side and requested to attach with a network message must be within range and pass every other check in server side code before attaching. This way it doesn't generally matter if the module system is public, since players can't affect the important script checks running on the server. Another example is the PW animation scripts on the server are checked to prevent players calling them too often and being annoying, with the server enforcing a cool down period; as opposed to (if I recall correctly, at least in early days) the animation scripts for Viking Conquest multiplayer, which were not even checked whether the right agent id was sent, so people with modified clients could force other player characters to stop and perform a specific animation using malicious request messages.

    My guess is that the exploit of dropping money bags with various (non official) money banking scripts is caused by not removing the money from the player on the warband server before sending the transfer request to the external web server and database: if the player tries to deposit money, the gold amount deposited should be checked and then removed immediately, probably storing the subtracted gold amount in a player slot (something like slot_player_unconfirmed_gold_amount_deposited, also a slot_player_time_gold_deposited with the current mission time), then sending the deposit message to the web server, and if the web server replies quickly enough with a successful deposit message, the player slots are cleared and the money remains unmodified, otherwise the server checks players every now and then with unconfirmed deposits a minute or so old, and refunds the undeposited money value to the player with an error message, so player gold isn't lost due to web server disconnections. Maybe if the server receives a deposit confirmation from the web server for a player without the unconfirmed slots set, the money should be subtracted from the player (in case the web server finally confirmed a deposit after the server gave up and refunded). The player should be prevented from making any further deposits or withdrawals while awating confirmation; alternatively you could only subtract the player gold after a web server transfer was confirmed, but try to make all scripts that deal with player gold fail if the player is marked as awaiting a bank transfer confirmation, so players couldn't drop money bags or buy anything until the bank transfer was confirmed to go through (or you could try overdrafts with penalty interest, jail time, or whatever other things real banks do).

    Any time a check is run then a message is sent off to make a modification based on that check in another process later on, race conditions could happen; so ideally the checks should happen immediately in the M&B script before the modification is completed, which since the module system interpreter is not multi threaded - to my knowledge - should prevent that type of exploit.

    Server messages or scripts run client side on a modified client should not affect the server, just desynchronize what that player sees compared with the server and everyone else: the section for handling events from the server will not run on a server, since it is inside a block starting with neg|multiplayer_is_server; so it should not affect anything if a modified client sends something like server_event_agent_equip_armor. I don't remember testing whether client scripts can run multiplayer_send_x_to_player operations to other clients, but it seems unlikely, and that would just mess up what the other player sees, not the gold, items, combat calculations, etc. stored on the server.

    If you are especially paranoid, it would be possible but annoying to maintain two code bases, with one module system that includes all code and is only run on the server, and a different but compatible module system with all server scripts removed, which is built and released to clients: the released module can then only be used to connect to servers, not host another server or check the server scripts for exploits. I thought about it for PW but decided it wasn't worth the bother, since I wanted to allow anybody in the world to host a server, and to eventually release all the code publicly anyway.
  5. Modding Q&A [For Quick Questions and Answers]

    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)?
    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.

    To make items equipped with agent_equip_item persist into the next round correctly with multiplayer game modes, you would need to carefully check all the scripts and mission template triggers that use player_add_spawn_item to ensure the correct items are kept; I would guess items equipped to the agent would work like for weapons picked up during the round. To get the agent id from the player id, use player_get_agent_id, and then check with agent_is_active to ensure the player is not spectating or just joined (which could cause errors with operations on the returned agent id, if so).
  6. Persistent Lord

    To elaborate on what I think domipoppe means: you could have an admin join the faction and then use the "lock current faction" admin tool, which disables creating a poll to change the lord (permanently keeping whoever is currently lord, until unlocked again). Otherwise, if you are creating a different sub mod, you could change the scripts to select lords a different way.
  7. Help!The scripting problem can't be solved.

    Log in to the server using SSH or something to the command line interface, start the mysql client, and create a new password according to the nameserver guide in README.txt (you will have to update your server strings.txt to the new encrypted password as well), or if you used some other web interface or service to install the PW mysql database, edit it that way. If you didn't set up the nameserver, ask the person who did.
  8. Resource Regrow Bug?

    Hmm: it is a very long time since I tested the fishing scripts, so I presume they still work fine, but don't know for sure.

    You could test more easily if you remove sokf_invisible from the pw_fish_school scene prop flags (to identify where they are), add a dbg.vars_display(":fish_count") line to the end of script move_fish_school (to see how many fish in each), and optionally reduce the normal 30 second interval between moving fish schools in the first line of the fish_school_loop trigger in module_mission_templates to speed the movement up (to quickly see where the fish schools can travel to - maybe they are just moving away from where you expect them to be).

    Also, does the troop you are using have labouring skill?
  9. Resource Regrow Bug?

    There is a quirk in the apple tree scripts that they do not regrow until they have been cut down by a player at least once since the server started: I decided not to fix it, because there seemed to be the beneficial side effect that for trees placed in locations where players didn't or couldn't go to, the server would not waste performance spawning unused apples. To make apple trees always spawn after server restart, you would just need to call script add_resource_to_regrow_list with each fruit tree instance id, similarly to how it is done at the end of script regrow_fruit_tree (which restarts the cycle after each time fruit grows or the tree is cut down).

    Fish schools should eventually regenerate even if totally fished out: see the end of script move_fish_school, which does:
    Code:
          (store_random_in_range, ":adjust_fish", -2, 4),
          (val_add, ":fish_count", ":adjust_fish"),
          (val_max, ":fish_count", 0),
    So while the fish school might not increase every time the check is run, overall it is about 3 times as likely to increase than decrease. I remember testing the fishing scripts extensively with debugging to the server console, and I'm pretty sure the regeneration worked correctly.
  10. Modding Q&A [For Quick Questions and Answers]

    Fearg said:
      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
        upgrade2(troops,"slave","farmer","looter")  #new
                    ^
    SyntaxError: invalid syntax
    It produces this for each process_X.py that deals with module_troops.py (so its just the same syntax error over and over)
    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.
  11. Bug reports and suggestions - read the first post

    Anani said:
    Is having both no_money and quick_battle possible?
    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, ":eek: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).
  12. Persistent World 4.5.1 - download and general discussion

    Anani said:
    Is there any way I can set 200, or 400 bots?
    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:
    Code:
    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),
    Anani said:
    should something like ''set_bots 200'' do the trick?
    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.
  13. Bug reports and suggestions - read the first post

    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.
    Baskakov_Dima said:
    Overall, the animations by Papa Lazarou just look a lot better, that's it. It's not even a "major" change.
    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.
  14. Bug reports and suggestions - read the first post

    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 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.

    Since then various combat related features and tweaks have been added, though mainly back when PW didn't have publicly available source code, and servers all used the official versions: nowdays just about every server runs a heavily hacked version of PW, often with script changes that they don't have the skill to update or apply themselves, so new module releases would probably be unwelcome, especially with major changes.
  15. Modding Q&A [For Quick Questions and Answers]

    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:
    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:

    Basic code
    Background information

    As kalarhan said, factions (starting with fac_) in the module system are not teams, and they are only really used in single player. Multiplayer modes just spawn agents (from troops) into teams; there are only 3 possible values for a player's team (0 = spectator, 1, and 2), and 8 possible agent team values (0, 1, 2, 3, 4, 5, 6, 7 = hard coded neutral no attack, from memory).
  16. Modding Q&A [For Quick Questions and Answers]

    domipoppe said:
    Code:
           (position_get_x, ":pos_x"),
           (position_get_y, ":pos_y"),
    Those operations have no position register parameter, and I think unset parameters are recognised as 0 (pos0).
  17. Persistent World 4.5.1 - download and general discussion

    cj4884305 said:
    (pw-scene-light)How does this light change his color
    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):
    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 flicker magnitude and flicker interval are passed directly on to the add_point_light_to_entity module system operation, which has this comment:
    header_operations.py said:
    flicker_magnitude between 0 and 100, flicker_interval is in 1/100 seconds
    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.
  18. Issue with new classes

    If you are properly creating a new mod, with identical module files on the server and all clients (not trying to make an incompatible server side change to official PW, which is not permitted by the usage conditions), the code should work fine: to add a new troop type, the only things that need to be done are to create the troop entry in module_troops.py, add a training scene prop entry with spr_change_troop_triggers(), and set the slots in script initialize_game_rules (slot_troop_ranking for the players in faction list, slot_troop_spawn_health_percent for the appropriate respawn health when the extra feature is enabled).

    The spr_change_troop_triggers generator function sets slot_scene_prop_troop_id for the training prop, which is checked in script game_get_use string whether it is a valid troop id before the else_try section that sets the default fallback "Use" popup. So the crucial thing is that the player client has all the correct troop and scene prop data in the module: the use string functionality is entirely client side, not touching the server at all except for stock counts, hit points, and castle names - relevant for other types of scene props.
  19. Persistent World 4.5.1 - download and general discussion

    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.
    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.
    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).
  20. Persistent World 4.5.1 - download and general discussion

    The_Ass_Man said:
    failed to load: resource/lod_armors_b.brf
    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.
    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.
Top Bottom