Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - boodals 2

Pages: [1] 2 3 4 5 6 ... 66
1
90% of the time, a syntax error is on the line above the one torque highlights.

2
Modification Help / Re: Missing ScriptObject/SimObject inheritance?
« on: January 05, 2016, 10:40:17 AM »
This is very odd, I have never heard nor seen anything like this. The only thing I could think of that could possibly cause something like this is a terribly badly made dll injected, or if some weird add-on is somehow breaking something within the OnAdd method. Run a trace, try with default add-ons, remove unnecessary lines, etc.

3
Modification Help / Re: fxLight - How to I mount a light on a head?
« on: December 12, 2015, 07:01:12 AM »
It would probably be better to
give a bot a light, make the bot invisible, and then mount the bot on someone's head.

4
Yeah, this is something that torque does. If you delete an object from a set/group, then the last object is put into its index, instead of having to shift all of the other objects down a slot. It can really screw you over if you're not expecting it and using sets/groups as an ordered container.

5
Modification Help / Re: How do I set a default player for a gamemode?
« on: November 25, 2015, 01:29:12 PM »
Pretty sure you can just set the minigame variables from the gamemode.txt

6
Development / Re: 2015/11/25 - Blockland 66% off on steam!
« on: November 25, 2015, 01:08:06 PM »
Oooh, nice

7
Modification Help / Re: Prevent specific bricks from being chainkilled
« on: November 21, 2015, 06:32:26 AM »
I believe there's an .isGrounded variable on bricks which is normally assigned when you plant it on the ground, not sure on the name though. Look up that add-on which let you place modter bricks in the air, pretty sure that used it.

8
Modification Help / Re: Detecting when player is damaged/health increases
« on: November 19, 2015, 09:07:26 AM »
Calling something an "incredibly bad way to do it" when it only has a couple quickly-fixed errors is misleading, especially for people who are learning because they think the whole thing must be crap when in fact you have to add a tiny amount of things to make it work properly

I get what you're saying, but minor differences in coding can mean very different things all the time. I was exaggerating it to make sure that new coders don't think "its only a couple of lines difference, i'm sure it'll be fine". Ideally Path would edit his post and fix it, and then i'll edit mine to avoid confusion, but I cant control that.

9
Modification Help / Re: Detecting when player is damaged/health increases
« on: November 18, 2015, 05:04:25 AM »
-snip-

This is an incredibly bad way to do it. If any other add-on uses this method, they will be incompatible. And this will only work if the player is using the standard player datablock, which for most practical uses, they will not be.

The correct way to do this would be to package armor::damage(%data, %obj, %sourceObject, %position, %damage, %damageType) so that it is fully compatible and works for all player types.

If you are making your own custom playertype datablock, and you only want this script to work for that datablock, then you can use yourDatablock::damage( ... ) as you know that nobody will be overwriting it.

Either way you should be calling parent::damage( ... ) so that the base damage script (and all other scripts packaging armor::damage( ... ) ) is called.

10
Modification Help / Re: Player Position relative to direction/vector
« on: November 18, 2015, 04:58:17 AM »
This resource might help you: http://forum.blockland.us/index.php?topic=270070

In addition, this is a similar problem to this topic: http://forum.blockland.us/index.php?topic=286014.0 only you are looking to do the reverse. You could in theory do the reverse of the solution I posted, and that should solve your problem.

11
I had a look at the result of getMuzzleVector and the muzzle vector doesn't appear to be changing when the player is looking at the ground.

That's not how it works.

When its true, it fires from the muzzle point to the point they are looking at, instead of firing it forward along the weapon. getMuzzleVector() is not affected by this in any way.

12
I think this is how most playertypes do similar things, so yeah its totally fine. (Other than you should be doing an isObject(%client.player) check)

13
Modification Help / Re: Raycast Explosion
« on: October 28, 2015, 06:54:59 PM »
Pretty sure all (default?) players/bots just have their world box size multiplied by 2, from the bottom center.

But yeah just do a box search of the ghost brick, which will find any player nearby, and then just do a manual box overlap check.

14
Modification Help / Re: Raycast Explosion
« on: October 23, 2015, 07:40:53 AM »
I believe there's a function which gets either the position or the distance to the thing the radius cast hit. I think its the distance though, but not sure.

Edit:

http://www-rohan.sdsu.edu/~stewart/GPGT/Appendix%20A%20-%20Quick%20References.pdf

No idea if this function is actually in BL though, or it might be renamed.

15
Modification Help / Re: Best Way To Search For Players In A Box [Solved]
« on: October 18, 2015, 06:49:19 AM »
I actually find it's easier to do the comparisons of X/Y/Z axis vs finding the distance from the center of the sphere

I disagree

            pl.x+pl.radius > box.x-(box.width/2) && pl.x-pl.radius < box.x+(box.width/2) &&
            pl.y+pl.radius > box.y-(box.length/2) && pl.y-pl.radius < box.y+(box.length/2) &&
            pl.z+pl.height > box.z-(box.height/2) && pl.z-pl.height < box.z+(box.height/2)

vs

Code: [Select]
            VectorDist(pl, box) < box.radius + pl.radius


Might be faster for the CPU though thanks to the square root operation in VectorDist.

Pages: [1] 2 3 4 5 6 ... 66