Search results

New version is now up on Moddb. Mod is now completely stable and freelancer is back.

Thanks for clarifying K700, that is a shame. I didn't use troop_set_type in this instance as I did not think it would change the agent skin in the middle of the battle which is what I need. As far as I am aware all changes using troop operations must be done before spawn or them to impact the battle, is that correct?

Azonthriel- that is weird, why would the GOG version be a trial? If you have further set up issues with warsword conquest then you can join our discord and hopefully some of our regular posters can help.

Whenever I use player_set_skin it always gives me a script error saying the player number is incorrect even if I use (get_player_agent_no, <destination>), right before it. Is the player_set_skin a multiplayer only operation? Some discussions I have found suggests it should be usable in single player.

Is it hardcoded that characters remove their helmets in conversations? I have checked the conversation_encounter mission template and other than override_horse nothing seems to be affected.

K700 said:

no wse operations change mods files

Click to expand...

Thanks you for the clarification I will make some changes.

Thanks for all your work on this K700, it has helped expand the scope of our latest release massively.

One question I have is about some of the wse operations. It has been reported that stat changes using this operation only last for that particular session and don't save permanently on the item, is this intended or is it supposed to save? (item_set_body_armor, <item_kind_no>, <value>),

When you are resting in a town and the besiegers pile in and attack you usually automatically get taken to the menu "siege_started_defender". However currently in it doesn't happen automatically, you have to click the screen to get there meaning you can miss an attack phase or even the whole fight if you are slow and the defensive garrison is small.

Trouble is I cannot find any code to initiate this automatic menu jump. The only place in the module where the player is sent to mnu_siege_started_defender is when you get to a town after a siege has started. I have look at the game_encounter and siege/ai processing scripts to see if I can find the instruction to activate the menu but I cannot find it.

Does anyone know? Is this particular interaction hardcoded (ai party to party) because without the code it is hard to see why the game is now ignoring the fact that the player is resting there when the siege starts.

Gsanders some of the things you have said or implied about the team members on here and modddb (thanks for deleting that) have been unjustified and unwarranted. You seem to have seen a normal testing session and built up your own narrative about what it meant in your head and decided to start attacking us based on that narrative. Virtually nothing of what you have said or implied since you started posting publically about this has been true.

I don't understand why you wouldn't just talk to us, I would never treat you like you have treated myself and the other team members in the last 24 hours. If you have grievances talk to us in the private on the relevant threads and you will see that you have grossly misinterpreted a great many things.

kalarhan said:

Nameless Warrior said:

In further investigation usually in "store_skill_level" a skill will be accepted whether you use "skl_ironflesh" or skl_ironflesh but similarly if I remove the speech marks it again says undefined.

Click to expand...

shows us code

and check your header_skills.py if the knows_XXXX is defined there properly.

btw you can rename it to something that makes sense, you do not need to use "reserved_XXX" as the skill reference.

Click to expand...

Yep, thanks for pointing me in the right direction. I had a brainfart and forgot to change the rest of headers after changing the skill.

I have created a new skill using reserved_1 in the skills.py in the same way I have with previous new skills and things seem to be fine.

When I am in scripts and using the store skill level operation it accepts the new skill and compiles.

However in troops if I try and say a troop knows this skill at a certain level it brings an error saying undefined.

Any idea why it would be?

In further investigation usually in "store_skill_level" a skill will be accepted whether you use "skl_ironflesh" or skl_ironflesh but similarly if I remove the speech marks it again says undefined.

Arsakes said:

Can you devs tell what is the "big" issue to be solved that was mentioned in latest Modb update while ago?

Click to expand...

The mod was displaying the wrong messages in the bottom corner throughout the game. For example when a non aggression pact was made a debug message came up and in battle instead of saying 'you will get x renown for this battle' it always said 'it's a trap'. About 3/4 of all the messages were wrong which made the mod unplayable. Funny you should mention it though as I finally fixed it yesterday.

kalarhan said:

Nameless Warrior said:

I have the latest module download on the forum which has  a header operations titled "header_operations expanded v.1.0.1" but the coding is as you say different on yours. What is that version called?  I just downloaded lavs and that also has the old code.

Click to expand...

VC modsys merged with Lav's headers, as operations for 1.153+ were created for the DLC. I also used it for the tweaks tool and the code can be found https://github.com/KalarhanWB/VC_Tweaks_Tool/tree/master/app

when you destroy a object it can take some time to cycle out of memory, so check the status by using a parameter like HP or a slot to filter it out. See how long they remain in use.

you can also maintain your own list of objects as they are created/destroyed, instead of relying on the engine to tell you who they are. There are even OSP code to implement lists, arrays, etc based on slots for easy coding (they are based on fake objects like a troop and slots).

Click to expand...

Thanks Kalarhan, some of those operation changes look very interesting. Shame the instance is still not being recorded at reg0 for spawn_scene_prop. Strange that has never worked when it does for spawn agent and horse.

Yes I use the troop based lists a lot, they are an amazing addition to community tools. I haven't used them for testing purposes yet but it is always an option. Luckily I didn't need to this time.

I created a scene_prop_activation_stage slot to monitor the scene prop status every second but the problem was I used reg1, reg2 and reg3 within the try_for_scene_prop loop and this gave me false readings. Once I used local variables and converted it to registers once the loop had finished it then gave me the correct reading and I can see that destroying the scene prop does indeed remove that instance number from the battle.

prop_instance_is_valid                      = 1838  # (prop_instance_is_valid, <scene_prop_instance_id>),
                                                    # Checks that the reference to a scene prop instance is valid (i.e. it was not removed).

It suggests in this operation description that there is a way to remove scene props from a battlefield. Does anyone know the way to do that? as there is no remove_scene_prop like there is a remove_agent and as there is a scene_prop_fade_in I don't think fade_out it works in that fashion.

What I am looking to do is spawn a scene prop and then remove it so that later calls of (try_for_prop_instances,":instances"), will not include these instances in the cycle.

I have done some testing and it seems that even after activating ti_on_scene_prop_destroy the prop is still considered on the battlefield and part of that loop.

kalarhan said:

Nameless Warrior said:

Any idea what can cause a phantom quickstring?

Click to expand...

likely a syntax error or a invalid character (that breaks the string split). Easiest way to track it down is to search the module file, as they are created in order. Find "closed the gate" and "to party morale" on your module_scripts.py and see what is between it.

you can also inject a logger on your process_XXX.py file if the manual search failed.

Code:

def load_quick_strings(export_dir):

def save_quick_strings(export_dir, quick_strings):

Click to expand...

Thanks. It turns out that {s0} is added in by modmerger and has always been there but missed it making me think that 569 one was wrong but now looking at it is indeed correct. The search continues.

Edit: for anyone who has this issue and finds this post I had a display message with no text after the @. That string will take an id but not a position in the txt file which will mess up everything underneath.

The player can still be a female elf and the witch elf lines are also using the same skin. With courtship gone there is no more good female elves around.

This post follows on from an issue I posted about on this thread in March

https://forums.taleworlds.com/index.php/topic,6575.msg8933517.html#msg8933517

I have finally found the culprit


This {s0} is being generated and it does not exist in module scripts and is not registering in the txt file code.  This is causing all quickstring calls underneath it in module scripts to display the quickstring below.

I have not been home to check yet but I reckon if I delete that line it will fix it but it will regenerate every time I compile so that is not a real solution. Any idea what can cause a phantom quickstring?

I have turned off the icon changing trigger when the space button is pressed and early reports are that the map lag has been reduced when fast travelling. I will look into further adjustments later.

Hope phantasy is going well gsanders

kalarhan said:

Nameless Warrior said:

How des that long number correspond to quick string positioning?

Click to expand...

it is posted above. Each type of data has a mask. You add the ID of the element to the mask (starting at 0) to generate the .txt file, and decrease from it to reverse from the .txt to the ID_xxx.py position.

quick string base code is 1585267068834414592

so a quick_string with ID = 1000 would be => 1585267068834414592 + 1000

if you take a quick string from "quick_strings.txt", the ID is line-2, so at line 150 the ID=148

Click to expand...

Thanks, I managed to do some calculations to match things up and in the end the answer was clear even without the numbers

qstr_{reg6}_spent_hiring_ {reg6}_spent_hiring_recruits
qstr_Prosperity_of_{s2}_h Prosperity_of_{s2}_has_changed_from_{s3}_to_{s4}.

It seems that when the game tries to call a quickstring it chooses the one beneath it. This matches all the other similar message issues we have been having. Just got to figure out why now. Am trying to see if there is a cut off point where the quickstrings stop working.

I think you are both on to something. I didn't consider it before but the sheer randomness and implausibility that the related scripts are being called significantly suggests that something is causing the quick strings to pull the wrong messages. When you start every battle you are told "you have entered a trap" and "{the leader of the enemy party you are fighting} wants you to keep following his army" instead of the normal tactics messages.

Just need to figure out what could have caused this. I don't believe I have used an / in a message, only ^ and they have always been fine. I will check tonight thoroughly tonight.

on quick_strings and string -> make sure you are updating your .txt files. You can check the script .txt code, find the ID of that quick string, and open it to see if the value generated was correct (should be).

(display_message, "@something"), => 1106 1 1585267xxxxxxxxxxxx
quick string base code is 1585267068834414592

Click to expand...

I have found the relevant code starting 1106 for (display_message, "@{reg6} spent hiring recruits"), and it is 158... and then a long number. How des that long number correspond to quick string positioning?

I seem to be having some random script, string, debug issues from out of nowhere. When you start a game you randomly get the some caravan attacked message 4 times before it gives you the stat 4, 4, 4,4 message and sends you to character creation. I just hashed out the cheat mode debug message for that although it was weird that even with cheat mode off it just does that at the start.

Big one now is that when you purchase recruits the message which comes up on screen is supposed to be...

(display_message, "@{reg6} spent hiring recruits"),

however the message which comes up is

(display_message, "@Prosperity of {s2} has changed from {s3  which is troop you have hired name} to {s4 which is nothing}."),

That message comes from change_center_prosperity and only when the player owns the location when that script is called. That message appears in every village you purchase recruits from and neither mnu_recruit_volunteers or script_village_recruit_volunteers_recruit call the prosperity script (and that seems to be the only place that message is called.  So 2 things are happening, the hiring recruits message is nto appearing and the prosperity one randomly is in it's place.

Anone have an idea what could be causing this? Quite a few little oddities like this has started to appear recently.