Tos on 1/12/2008 at 00:20

---

That's great. We actually didn't test too many FMs -- I think we did try Equilibrium, but didn't manage to finish it (or any other fan missions, for that matter). I'm glad to hear that you were able to.



Water arrows can be picked up because their pickup object (the crystal) is separate from the actual water arrow projectile. If all other arrows were like that, this problem wouldn't exist.

It might be possible to do what you're suggesting, but you still wouldn't be able to pick up broadheads that were pre-placed on the map using the old object. You also wouldn't be able to retrieve broadheads that were fired into wood, since that will use the actual projectile object that cannot be picked up.

If the CollisionStick script for broadheads and rope arrows could be modified to change the object's networking category to hosted (but only for the real object, and not the local copies that appear on other player's machines) upon running, it might allow you to retrieve your own arrows at least. It wouldn't allow you to pick up pre-placed ones though.



I'm not familiar with this one. Do you mean every player's name is shown as being the same in the top left when they're chatting? Can you reproduce this bug?

We noticed some odd problems with the player names during testing, but they only happened infrequently and were thus fairly difficult to track down. If you can figure out how to cause it though, I might be able to fix it.



I believe that the engine is limited to a single starting point for each map, and T2 MP will always respawn dead players at that point. There may be some sort of elaborate trickery you can do with DromEd to get different starting points though -- I don't know.



Yes, that should be possible. It'd probably require having different starting points for each player though, or everyone would end up killing each other over and over again after the game starts.



I'm still working on the project, so I'm sure some of them will be eventually. You can expect an update to fix some text rendering issues and add an option to disable player vs. player damage, if nothing else in the near term.



My guess would be that it would prevent anyone from joining. I'm fairly sure that the game will crash with more than 8 players anyways, since one of the arrays that holds player object data is only large enough for that many. If this is the only thing preventing 8+ players from working, I might be able to increase the size in the future.

Support for 8 players is actually just theoretical at the moment, anyways. The game was originally hard coded to only allow up to 4 players to connect (like SS2), but I changed it to 8 since I didn't find anything in the code to suggest that that wouldn't work. It's never been tested with more than 4 though, so we'll see how that works out once someone tries it.

(Are you changing this directly through the .ini, by the way? I didn't think you could select fewer than 2 through the interface.)

bob_doe_nz on 1/12/2008 at 00:30

---

I'm giggling like a small girl. :joke: That looks like fun.

jtr7 on 1/12/2008 at 00:46

---

Oh man, talk about an exploit! Have taffers standing at the spawn points for all the guards that appear when the blueprints are frobbed. I've already placed mines in those spots before.

Tos on 1/12/2008 at 00:57

---

Hmm, that bug has been around since day one. I hadn't seen it in a while though.

It may be being caused by a bug I inadvertently introduced into the build you're using now (184), and has already been fixed in the latest one. It will be in the next update. Funnily enough, I stumbled across the problem while implementing the option to disable player vs. player damage that you suggested. So, thanks. :p



That may be possible.

The game no longer uses those default avatar archetypes though -- T2 MP creates its own archetype (named MP Avatar) when the gamesys is loaded and uses that for all players. This was necessary to get multiplayer working with an unmodified gamesys, but it unfortunately means that the avatar properties (including the model used) are now hard coded and can't be changed with DromEd. I might be able to add a few more archetypes with different models, but it won't be user-editable.



I'm sending you a PM about this. Hopefully we can figure out what's wrong...

Hiatus on 1/12/2008 at 11:22

---

@Tos:

I've looked at both .400 and .445 .exes and I think they are practically identical (offsets are the same, I think) - only meaningful diff. is that .445 has something from (probably some function call - GetSystemInfo?) from 1FDAC6 to 1FDADD whereas .400 is zeroed there (no call). Could you check it out (what's at that offset)? Size difference is because sth is appended at the very end of .445 file (missing in .400). So I think manual edit/patcher should work for .400 as well (I'll try it out later). That means generic patcher is no problem.