Best way to structure an API around adding forces?

[thebest108]

I want to make an API that allows forces to be sent to a rigid-body from inside a Block or TileEntity. I'm thinking of having 2 types of forces to add, a one-off that will apply that force for 1 tick, and a passive one that adds the force to a HashMap containing the blockPos and the corresponding force. This is how I've been adding forces at the moment.

 

public void calculateForces(){
	torque.zero();
	translationForces.multiply(.;
	for(BlockPos pos:parent.blockPositions){
		if(pos!=null&&weightAtPos.containsKey(pos)){
			Vector inBodyWO = BigBastardMath.getBodyPosWithOrientation(pos, centerOfMass, parent.rotationTransform);
			Vector forceActing = new Vector(0.0D,-9.8D*weightAtPos.get(pos),0.0D);
			double distance = inBodyWO.length();
			if(parent.region.getBlockState(pos).getBlock().equals(Blocks.wool)){
				forceActing.add(new Vector(0.0D,200D,0.0D));
			}
			if(parent.region.getBlockState(pos).getBlock().equals(Blocks.iron_block)){
				Vector newForce = new Vector(200.0D,0.0D,0.0D);
				Rotations.applyTransform(parent.rotationTransform,newForce);
				forceActing.add(newForce);
			}
			torque.add(inBodyWO.cross(forceActing));
			translationForces.add(forceActing);
		}
	}

 

By default the forceActing vector is just the mass of the block times the gravity on the ship. The vector inBodyWO is the block's position with respect to the center of mass and the ship's orientation. The only thing adding forces here is the 2 if-statements checking if the block is Wool or Iron, and there it adds a "passive" force. The wool block doing an up-force, and the iron block doing a force on its East-Side. I'd record something but Im programming on a chromebook at the moment.

 

Anyway you guys are better programmers than me, how should I structure an API that allows blocks/tileEntities to add forces to the rigid-body so that other mods could program engines and crap (Like an ic2 engine that powers your airship)

[coolAlias]

Typically people don't set out to 'make an API' for something they don't themselves intend to do. If you're not making an engine or some such that will need this API, chances are your API will not be very good for the simple fact that you aren't actually using it, so there will be lots of cases that you won't think of and it may not even provided the functionality modders will ultimately need.

 

Also, consider that any mod already containing engines and such things are 99.9999% likely to continue doing it the way they always have been, even if your API turned out to be the best thing since canned meat. You should really think about who your target audience is, if any, for this API, and if it is even needed. Is there a compatibility problem you are trying to solve? How many 'standards' have already been developed, and what is their current usage? Do you think we need another one?

 

I'm not trying to be a downer here, just posing some realistic questions you should ask yourself before undertaking what could prove to be a complete waste of your time, unless of course you are doing it to learn, in which case go right ahead.

 

If you do go ahead with it, stuff like this:

if(parent.region.getBlockState(pos).getBlock().equals(Blocks.iron_block)){

is going to be a big problem. Sure, that's for a vanilla block, but wherever you can, you want to use interfaces. If you can't for whatever reason (such as for vanilla blocks), then you need to code in a way that lets you leave the public-facing API the same while still being able to tweak the internals.

 

So, for example, the two if statements inside your code block there that check the blockstate, I would rewrite to be something like this:

Block block = parent.region.getBlockState(pos).getBlock();
Vector newForce = null;
if (block instanceof IForceBlock) {
  newForce = ((IForceBlock) block).getForce(world, state, pos); // and whatever other parameters you need
} else {
  newForce = getForceForVanillaBlock(state, pos); // and whatever other parameters you need
}
if (newForce != null) { // assuming both are handled the same
  // apply rotation, add force to collection, etc.
}

`getForceForVanillaBlock` could simply return a value from an immutable hashmap containing Block:Vector pairs that you populate at run-time; you could even allow mods to add their own blocks to this map via inter-mod messages, if you want.

 

There are a lot of ways you can go about it, but always prefer abstraction and interfaces to hard-coding specific values.

[thebest108]

Cool, I think I've covered it with 2 small interfaces. I know more API's are a pain so I've made it as small and simple as possible. This takes literally 5 minutes to add to anything.

 

package FlyingFortress.API;

import net.minecraft.block.state.IBlockState;
import net.minecraft.util.BlockPos;
import net.minecraft.util.Vec3;
import net.minecraft.world.World;

//An interface a block can implement this to add its own forces to the Rigid-Bodies
public interface IForceBlock {

//Note that this Vector should inculde the effects of gravity
public Vec3 getForceActing(World world, IBlockState state,BlockPos pos);

//false for things that aren't directional like Balloons, true for things that are like Engines
public boolean isForceInLocal(World world,IBlockState state,BlockPos pos);

}

 

package FlyingFortress.API;

import net.minecraft.util.Vec3;
import net.minecraft.world.World;

public interface IForceEntity {

public boolean isForceInLocal(World shipWorld,Vec3 localPosInShipWorld);

//Called every tick when an entity is "inside" of a Ship
public Vec3 getForceActingIn(World shipWorld,Vec3 localPosInShipWorld);

}

 

1 last question, how do I setup the classpath so that when other mods use these classes only 1 instance of these classes are loaded at runtime?

[coolAlias]

You don't set up anything - the implementing mods shouldn't be including your API with their .jar in the first place, so your copy is the only copy. They should use the @Optional annotation to strip your interfaces and methods if your mod is not present.