Modding Q&A [For Quick Questions and Answers]

Users who are viewing this thread

Total: 7 (members: 0, guests: 7)
Status
Not open for further replies.
this si what it says whenever i try to select my swedish helm, the coding is all correct except something is wrong with the msh, eitheir i have selected the wrong mesh or m&b can not find the brf folder, please help me
 
teun557 said:
Hey, I have model and I have it UV mapped, what is a good program to add the texture?
Click to expand...
You can texture in many programs. What I know of for free Gimp is your best bet though I think you can with Paint.net. Personally I paid for a license an all that and got Photoshop CS 5.5
 
Ok, so simple question which I can't seem to find an answer to by searching around the forums. For changes I make do I always have to start a new game to see them take effect? Or are there only certain things that need a new game to see?


Also, after adding companions I've noticed that the existing ones have all had their dialogue shifted slightly in regards to their likes/dislikes and home info speeches. Ie, Jeremus talking about being an old lady when leaving the company. Did I misplace/remove a comma or paratheses? Or is there something else that's causing this? I've been looking through the Module_strings file but so far I can't find anything. Knowing exactly what I should be looking for would help immensely in tracking it down.

Note: I am not running into an Error, there's just a dialogue shift.
 
Reference changes do not need a new game to take effect (if you change a slot number, new scripts will be used immediately), but entity and data changes should need a new game (content of slots will not update, creating a new troops shifts everything down). The game is dependent on offsets for plenty of things - companions, for instance are 16 in number, and so the unique strings for each situation are 16 in number. By subtracting Borcha from the companion's troop id, we get an offset of which companion this is, which is then added to the starting string. If you add a new companion in, a lot of offsets will be skewed. Therefore, we endeavour to add things at the end, which won't cause shifting for entities before it, but the problem with pre-set limits remain (16 companions).
Just look for #NPC strings in module_strings, and add 1 for each new NPC. There's a tutorial somewhere. They are pretty self-explanatory, but keep in mind that some are never used in Native, which are marked with {!} (which tells the game to not export it for translation).
 
Could you expand on what you mean by reference, entity and data changes? Or point me to something that gives me a little more depth? I'm relatively new at this so I must apologize if this is a dumb question, but what you said makes very little sense to me and I would like a clear idea of what to put in place before I make a serious attempt at a playthrough.


The tutorial is here: http://forums.taleworlds.com/index.php/topic,130815.0.html

That's what I followed. All original companions are completely intact and my new ones are all added as options afterwards. The companion number has been adjusted accordingly, and each section of the module_strings has an additional line for each new companion. Should I be looking then for a skipped dialogue? I.e, a jump from npc 17 to 19?


 
Say we have a companion, Borcha. By default he looks like a horse thief, and wears a khergit armor. He's a troop entity. What he's wearing and his stats are data saved in the savegame so those require a new game to update. If you place an item before the khergit armor, he'll have the new item in his armor slot (which isn't a good thing) and every item after that is also screwed up in hero inventories.
Now, your party consists of yourself, Borcha, and a Farmer. If you put something before the Farmer, he'll get bumped down and you won't see him in your party. Say you change the farmer to be also able to upgrade to a bandit. That change is a reference between the farmer and bandit which will apply in your savegame.
Slots are data much like troop inventories. Pretty much everything you'll see in module_constant is a reference, but the game doesn't care what your references were called in the module system - it's all compiled into numbers now. So if Borcha's slot_troop_morality_type had a value of tmt_honest=4, and you later shifted slots so that slot_troop_morality_type = 63, the script accessing an older savegame will instead access what was slot_troop_morality_value.
 
How would I check if someone was killed by a headshot? Is there an easier way than checking the hit position in a "ti_on_agent_hi" trigger?
 
OK, thank you. Too bad that is it so hard, though.

edit: I got another problem:
IT_score_system = (ti_on_agent_hit, 0, 0, [],#score system
    [
    (store_trigger_param_1, ":target"),#he who was hit
    (store_trigger_param_2, ":hitter"),#this one becomes points
       
    (neq, ":target", ":hitter"),#no points for killing yourself
        (player_get_slot,":hitter_point_score",":hitter",slot_player_point_score),
        (val_add,":hitter_point_score",10),
        (player_set_slot,":hitter",slot_player_point_score,":hitter_point_score"),
    ])
Click to expand...
I always get a "invalid player id: 15" error for the player_set_slot and player_get_slot. But the trigger is not wrong, or is it? I don't see any mistakes taht could cause the error.

edit2: Tested it, the error seems to be different each time, it is not always "15" but other numbers too.
 
xenoargh said:
Got stuck on something, wanted to know if anybody could clue me in.

I need to rotate a position to point at an Agent.  How do I do that?
Click to expand...
I'm not sure if there's an easier way, but the following is the script that motomataru developed to do this:
Code: 
  # script_point_y_toward_position by motomataru
  # Input: from position, to position
  # Output: reg0 fixed point distance
  ("point_y_toward_position", [
	(store_script_param, ":from_position", 1),
	(store_script_param, ":to_position", 2),
	(position_get_x, ":dist_x_to_cosine", ":to_position"),
	(position_get_x, ":from_coord", ":from_position"),
	(val_sub, ":dist_x_to_cosine", ":from_coord"),
	(store_mul, ":sum_square", ":dist_x_to_cosine", ":dist_x_to_cosine"),
	(position_get_y, ":dist_y_to_sine", ":to_position"),
	(position_get_y, ":from_coord", ":from_position"),
	(val_sub, ":dist_y_to_sine", ":from_coord"),
	(store_mul, reg0, ":dist_y_to_sine", ":dist_y_to_sine"),
	(val_add, ":sum_square", reg0),
	(convert_from_fixed_point, ":sum_square"),
	(store_sqrt, ":distance_between", ":sum_square"),
	(try_begin),
		(gt, ":distance_between", 0),
		(convert_to_fixed_point, ":dist_x_to_cosine"),
		(val_div, ":dist_x_to_cosine", ":distance_between"),
		(convert_to_fixed_point, ":dist_y_to_sine"),
		(val_div, ":dist_y_to_sine", ":distance_between"),
		(try_begin),
			(lt, ":dist_x_to_cosine", 0),
			(assign, ":bound_a", 90),
			(assign, ":bound_b", 270),
			(assign, ":theta", 180),
		(else_try),
			(assign, ":bound_a", 90),
			(assign, ":bound_b", -90),
			(assign, ":theta", 0),
		(try_end),
		(assign, ":sine_theta", 0),	#avoid error on compile
		(convert_to_fixed_point, ":theta"),
		(convert_to_fixed_point, ":bound_a"),
		(convert_to_fixed_point, ":bound_b"),
		(try_for_range, reg0, 0, 6),	#precision 90/2exp6 (around 2 degrees)
			(store_sin, ":sine_theta", ":theta"),
			(try_begin),
				(gt, ":sine_theta", ":dist_y_to_sine"),
				(assign, ":bound_a", ":theta"),
			(else_try),
				(lt, ":sine_theta", ":dist_y_to_sine"),
				(assign, ":bound_b", ":theta"),
			(try_end),
			(store_add, ":angle_sum", ":bound_b", ":bound_a"),
			(store_div, ":theta", ":angle_sum", 2),
		(try_end),
		(convert_from_fixed_point, ":theta"),
		(position_get_rotation_around_z, reg0, ":from_position"),
		(val_sub, ":theta", reg0),
		(val_sub, ":theta", 90),	#point y-axis at destination
		(position_rotate_z, ":from_position", ":theta"),
	(try_end),
	
	(assign, reg0, ":distance_between"),
  ]),
 
Wow, I wasn't expecting it to be that complicated, but that's OK, it can be expensive.  I'm having some problems with the Aleph when AIs pilot it and I need to fix how it aims at stuff, basically force it to point a position at the Agent it's aiming at.
 
I wonder if you wouldn't be able to simplify it starting with something like
Code: 
(position_transform_position_to_local, pos_trans, pos_source, pos_target),
(position_get_y, ":y", pos_trans),
(position_get_x, ":x", pos_trans),
(store_atan2, ":theta", ":y", ":x"),
 
Well, no time like the present to give it a go.  Basically, the problem is that the aim position for giant-sized Agents doesn't match up with their bones; it's some sort of hardcoded point in space.  This creates big problems when the Agent's supposed to be aiming at something a long way off and the difference in position is 3 meters. 

I'll probably also have to get rid of gravity / friction on that weapon- in fact, maybe that'll get it close enough...

But I really need to fix this.  I've gotten to watch the poor Aleph shooting up empty fields over and over again, trying to hit one poor guy at the end of a battle  :lol:
 
Status
Not open for further replies.

Similar threads

laius
Disable impact of specific face slider on helmet/hair rigging?
Replies
2
Views
235
laius
laius
Pentagathoos
Immersive strategic/campaign features [ideas]
Replies
0
Views
186
Pentagathoos
Pentagathoos
[Native 1.174] Very easy request. How to force enemy AI to always charge immediately?
Replies
2
Views
222
aleeque
Back
Top Bottom