Forums

---

I was surprised to learn today that there are apparently no strifle-wielding tuskens in the Ka'Pa Palace level And for that matter, I think there are only the brown tuskens in the level/entire game (no grey ones). I have no idea how I failed to notice this before (maybe because the enemy set is rather diverse in the first place? -- gran, rodians, ithorians, tuskens, gammoreans, etc...)

Anyway, you are encountering a template problem - the fireoffset param in the template is wrong.

I made two new templates for the two tuskens (with fixed fireoffset values). You can copy/paste these at the end of your mots.tpl file (in your project directory), then in Zed, do "Commands -> Reload Templates" to import your changes.

# DESC: Tusken with strifle # BBOX: -.04 -.01 -.12 .04 .02 .07 tuskangun2        tuskangun          fireoffset=(.035/.0682/-.01) # DESC: Tusken with bowcaster # BBOX: -.04 -.01 -.12 .05 .06 .07 tuskan2           tuskan             fireoffset=(.035/.0682/-.01)

You may or not want to tweak the offsets a little more, but I'll leave that to you

(P.s. if you don't have a mots.tpl in your project directory, copy the one from Jeddata in your Zed directory)

---

Oops, I got so caught up with the fireoffset that I completely forgot about the blastech issue.

Anyway, it's just a small adjustment to the strifle tusken's actor cog to fix that. Basically, the cog is creating a powerup template that (A) is the wrong weapon (Blastech), and (B) does not have a cog attached (making it impossible to pick up). We need to (1) fix the tusken's cog, and (2) make the template use it.

• Extract actor_tb_pnch.cog from JKMRES.GOO
  
• Open the cog, and toward the top you should see a line that reads:
  

  template    powerup=+DBlastechPistol         local

  
  
• Change that line to:
  

  template    powerup=+DSTrifle         local

  
  
• Save the cog. Make sure the cog is saved in your PROJECT_DIRECTORY\cog directory (name it actor_tb_pnch2.cog or something else to prevent conflicts with the original file)
  (Item 1 complete)
  
• Modify the template I gave you before so it reads:
  

  # DESC: Tusken with strifle # BBOX: -.04 -.01 -.12 .04 .02 .07 tuskangun2        tuskangun          fireoffset=(.035/.0682/-.01) cog=actor_tb_pnch2.cog

  
  (Don't forget to reload templates in Zed)
  (Item 2 complete)
  

The advantage to this solution (versus just copying the JK template) is that you get to retain the punching behavior that follows force-pulling the strifle tusken's weapon.

---

One other thing, when it comes to templates. I added a new .3do to my level, in the usual way. However, while it looks fine in Zed, the 3do in-game is just a small cube in the grey default texture. Here's the exerpt from the .tpl:

bigdeadtree treestump1-b size=.732617 movesize=.732617 model3d=bigdeadtree.3DO
# DESC:
# BBOX: -.15 -.15 -.72 .23 .22 .46

Thanks again.

---

Hi again,

It's a 3do I downloaded from Massassi, and I think it is a problem with the 3do itself, since I've been adding other 3do's which work fine.

I've used a variety of parent templates, but each one produces the same effect. Anyway, I'm going to just email you the 3do file, and you can have a look at the treestump template as well.

Thanks

---

(Darth_Stewie -- skip to the end of my post if you just want your solution )

===========================================

(Original Draft Post - preserved simply for reference/documentation purposes)

If the texture vertex limit is indeed 512, then bigdeadtree.3do is way past that limit at 782 texture vertices.

I recall various discussions, experimentations, etc. of the texture vertex limits and vertex limits. Most notably, I recall this one. What I have seen in JK myself tends to conform to the description in the original post, so I use that as my guideline (I.e. keep everything below 512). This includes one recent experience where I merged 6 surfaces into 1 to drop a 3do's poly count from 516 to 511, after doing so JK was happy (final texture vertex count on that model was 348 btw).

Of course, I tend to dwell in simple, testing box levels, rather than full-blown production levels... that may be part of why I haven't seen any odd deviations, but anyway...

I thought that one of the Hub references on 3dos mentioned at least one of texture vertex or surface limits, but I can find neither... hmm...

===========================================

AFTER SOME TESTING RELATED TO THE BIGDEADTREE.3DO ...

Hmm, based on my testing, it appears that MotS (if not also JK) may have a texture vertex limit at 768 ( = 512 + 256 ... coincidence? ).

I imported and exported with Zed, which dropped the texture vertex count from 782 to 761 (supposedly omitting duplicate texture vertices). This was the only difference between the two copies of the model that should have been causing a problem. I tried transplanting the surface normals, hierarchy, etc. between the two models, but no changes occurred.

After I added some texture vertices to the "after" model, it broke again. I found that at 768 texture vertices, the model rendered fine as a tree in-game, then at 769, it went to dflt-cube in-game. (These texture vertices I added are not referenced in any surface lines... they are only listed).

Check it out here:
http://www.jkhub.net/project/get.php?id=2106

Sorry this post got so wordy... just trying to provide information on the topic.

(On a side note, this seems oddly familiar... does anyone know -- has this result been discussed/encountered elsewhere before?)

===========================================

SOLUTION FOR DARTH_STEWIE

Just import and export the original bigdeadtree.3DO in Zed, and that should do the trick (it did for me)

---

Darthslaw, thank you for that research. Though, I am curious, how are you finding the texture vertex count? The best way I can think of to find this limit would be to use forceremap on a 3do with 1 texture on it. The 3do would need to have 512 Surfaces and 512 Vertices. Then you would adjust the texture scale in forceremap, which would change the UV of the textures on the 3do.

---

Good stuff. Thank you!