Search results for query: *

This may have already come up, but the search function is down.

I'm trying to add an entry point to the arena in Dhirim so that I can have an npc in my party show up under certain conditions. I went into edit mode and tried adding a point (it was auto-labeled as 17), and the character did show up... but he was acting as a melee participant and just kept trying to run at the guys down in the arena proper. I then moved that entry point down into the arena and made a new one, labeling it as 60 and adjusting the text accordingly, but now the guy won't show up at all. I know my code works, else it wouldn't have worked for entry point 17, so it must have something to do with the entry point itself.

Is there something I have to do in the Edit Mode to make the character appear?

And here I was trying to get it equal to 16. Silly me.

That did the job. Thanks!

I had to scour the scripts file a dozen times to find it, but it was indeed a missing parentheses bracket. Thanks again, guys!

MadocComadrin's right, I was doing gender-based dialog. The entire speech was set to be different based upon the player's gender, because the NPC treats men and women in very different ways. But at any rate I now know that the nested brackets {} wasn't causing the problem, as I rewrote all the scripts that had it and the error didn't go away.

If you'd read the entire query, you'd find that I did read that. It doesn't answer the question.

But Caba'drin did, for which I thank him.

Well, that's not it. I switched all the dialog - and found a few extra errors - and corrected it all, but I'm still getting the same error in the builder.

Well, it's not a missed bracket, I'm pretty sure. But let me ask this: can you have a {} code within a {} code? Here's an example:


I did this a couple times throughout the dialog, and it abruptly dawns upon me that something like this might confuse the system.

Missed a bracket? Curious, I don't remember coming across any brackets in the scripts file for me to delete (there aren't hardly in it to begin with, and none of them are anywhere near where I was editing). I would have had to have accidentally added one in somewhere.

Alright, I'll scour the scripts for a bit. Thanks.

So what you're saying is that after I create a personalitymatch2 constant for Paul and set it in his script to - for example - Artimenner (npc15), I'd have to go to npc15 and add personalitymatch2 to Artimenner's code so that he also has a match with Paul. I'd also essentially have to use the search function in every module_***.py file to find 'personalitymatch' and edit it to try and find multiple matches. I think I can do that, if they all function the way I think them to.

My <365 check was going to be set before the script was called in the first place, but thinking back on it I suppose it would be easier in the long run to have it in the script, as well. Also, I added the ":date_out" variable because I thought it would be easier to read and understand.

So that's what the val_mod does! I was wondering. I recognized all the other mathematical operations, but that one had me kinda stumped. And you're right, it's perfect for my needs.

I also took a look at script_game_get_date_text and think it would make a good template for my purposes (also, I note that the programmers did, in fact, include leap years). I think there's a typo in the notes for it, though - they say the input is the number of days that have passed, and yet the very first thing they do is divide the input by 24 into a variable called :num_days. I'm pretty sure that they meant to say that the input variable was in the number of hours that have passed. Just so you can see what I'm talking about:


At any rate, dunde has a very good point: I can simply copy-paste the conditional portion of script_game_get_date_text in order to determine the date for my purposes, and it's a heck of a lot easier than figuring all of it out from scratch. Not that I don't think the method we were discussing would work, but why rebuild something from scratch if there's already a perfectly working frame? It was still a great learning experience, though. The whole thing would seem like overkill for just one time-dependent character, but it just so happens that I've been planning 6 of them all along (two months per character), so I can use a single script to call them all whenever it is his/her time.

One of the things I didn't realize until just now is that the characters in a scene is determined by module_game_menus.py. All this time I was thinking that served an entirely different function. I've hardly looked at that particular file, so now I'm going to have to spend some time studying it and trying to figure out how it works. As far as I can tell, there are two potential ways to do this:

1) Add the hero troop in the game_menus' "tavern" code, with the date-dependent conditionals.
2) Create a new trigger that calls a date-checking script, and add the hero with the trigger.

The first one requires me to learn the most new material, so I'm probably going to go for that one.

On a somewhat related note: if a script can call itself recursively up to 250 times, and we are using my earlier script to determine dates, that means that the script would work up to 250 years! Now obviously nobody's gonna be playing a game that long, but it leads me to another question that I keep wondering about: all the lords in this game have a set age. I've never gone longer than a year myself, and so never really had the chance to find out... but do the characters age as they grow older? I noticed there are 'retirement' scripts in the game, but it seems to be limited to the pc and companions. In that case, can people die of old age? I can't help but think that this game would be made a lot more deep if there were some sort of aging|childbearing|retiring|death-by-age|heir features. After all, some of the lords in the game start off pretty old.

Okay, so I've figured out a few more things, but there's still others I don't understand.

First, I want to check to make sure I understand how the else_try operation works. I've designed a new script that is meant to take the value of store_current_day and return a value between 0 and 364, thus granting a way to determine what day of the year it is (and what month by extension). Since the game begins on March 23, I assumed that date as a 0 starting point, so numbers 0 - 8 make up March 23 - March 31, and numbers 343-364 constitute March 1 - March 22. The rest of the dates can be determined from this format. Note that I'm ignoring leap years and generally assuming that the game makers didn't bother to add leap years into the system.


What I'm uncertain of is whether this code will perform the looping equation I'm after. If this code works, then setting up the conditionals for when my hero shows up is easy.

The problem: I can't figure out where to set the conditional in the first place. I only see the 'set_visitor' operation used in the module_scripts.py file, but after searching the various other module_ files I can't figure out how the game knows where the troop is supposed to be added, as I don't see any coded references to a scene. I tried searching for the scripts themselves but can't seem to find them save for when they're being referenced by other scripts.

That said, I've thought of another potential way to do it, although it may require more code in the end. I was thinking about using the add_troop_to_site trigger mentioned by Somebody to spawn my new hero in a tavern, and then using remove_troop_from_site to get rid of the hero after the appropriate date. Is there any reason for this not to work?

EDIT: Holy smackerdoodles, it's 4:10 AM. I'm going to bed.

Okay, thanks!

I'm gradually coming to realize that I don't know what 95% of the operations do, but that's the whole point of this little project I'm working on, I suppose.

Okay, after a bit of studying I think I understand how set_visitor works and how to use it for my purpose. However there are still two things that I'm unclear about:

1) I understand that 'store_current_day' saves a number... but what number? Is it the the current day of the year between 1 and 365? Is it by days since the game began? I can find no information on this amongst the files. I'd just test it instead of asking, but let's face it: testing such a thing could take ages. Unless there's a way to jump to a date in-game that I haven't heard of yet.

2) I'm not sure what you mean by increasing the entry point. The whole point of this little exercise is to learn about how scripts and scenes work, so I'm still foggy on a lot of areas. Right now I don't know a thing about how the entry points work save that they are where the different troops spawn.

I keep hoping to use the modding wiki to resolve some of these questions, but it's been down all day.

Okay, I think I understand that. I'll do some experimenting and see if I can get it to work. Thanks!

Thanks and thanks again! This all makes a lot more sense now. You guys be awesome. I'll be sure to keep Themendios in mind if I have other questions, and I'll be checking that syntax thread immediately.

Cernunos

Oh good, I was making sense after all.

So that means the gold and renown tuples you showed me would go into the red brackets. If the condition I state is true, then this dialog is used. If it's not true, it moves on to the next dialog with the same label (in this case, another dialog designated as "paul_driardin_intro_c"). From what I understand, I should always put conditional-dependent dialogs above those dialogs with no conditions, so that the non-conditioned dialog would be the final result if all the others end up being false. Right?

The orange brackets are the effects that will occur if this dialog is chosen, such as earning the Hero as a new party companion. That I get. They aren't related to the conditional in the red bracket, save that if the conditional in the red bracket is false then the effects won't occur.

Two more questions:

First: I think I understand this, but I want to be sure. If I give two dialogs of the same designation that the player can say, without conditions or with conditions that are both true, both dialogs show up as options for the player to choose manually, yes?

Second: if I use the 'store' function to create a variable, does that variable remain present throughout the module_dialog.pv file? In other words, can I define the variable in one dialog, then use it again in another down the line, provided I haven't redefined it at some point? Or do I have to redefine the variable every time it comes up? I imagine it's the first option, with what little coding knowledge I do possess, but I want to be sure.

Somebody

So what you're saying is the operation 'troop_get_type' checks the gender of the player and assigns a value of 0 for male or 1 for female, am I right?

To make sure I understand: a lhs operation assigns values while a cf operation checks to see if a certain value meets a condition.

So, just for example, if I were to use slot_item_base_price and looked up, say, itm_tools, it would check for the base denar value of the tools item (410) for me to use in a condition. Alternatively, I could use the operation 'player_has_item' to check to see if the player has itm_tools, and if s/he does I can arrange a result. So it's the difference between saying 'How does X compare to Y?' and a simple yes or no question.

Ah, binary, I certainly do understand that. That makes a lot more sense.

Thanks to both of you, I'm finally beginning to understand this stuff! Assuming, of course, that everything I said above is accurate.