[contracts] Compute all config rather than store in state

[ponderingdemocritus]

Currently throughout the app when we use a config value in models, we read the config then store that in the state of a model.

This hard codes the config value for all future interactions with this model.

We need to move this so all config values are computed on the fly, rather than hard coding when a model is created. This will reduce gas costs, and also allow the config to change within a session.

---

This issue basically concerns the CapacityConfig and SpeedConfig.


Regarding capacity configuration, you'll see that we hardcode the Capacity value of entities here

eternum/contracts/src/systems/combat/contracts.cairo

Line 120 in cc2089f

Capacity { entity_id: army.entity_id, weight_gram: troop_capacity.weight_gram },

instead of doing that, we could store the entity type of in the EntityMetadata model
then whenever we need to get the capacity of the entity, we can get it by checking the current capacity config value of the entity type e.g

let entity_metadata: EntotyMetadata = get!(world, entity_id, EntityMetadata);
let capacity : CapacityConfig = CapacityConfigImpl::get(world, entity_metadata.entity_type);

then we use the capacity computed on the fly when determining the weight of entities

eternum/contracts/src/models/weight.cairo

Lines 10 to 35 in cc2089f

	#[generate_trait]
	impl WeightImpl of WeightTrait {
	fn deduct(ref self: Weight, capacity: Capacity, amount: u128) {
	if self.entity_id == 0 {
	return;
	};
	if capacity.is_capped() {
	assert(self.value >= amount, 'not enough weight');
	if amount > self.value {
	self.value = 0;
	} else {
	self.value -= amount;
	}
	}
	}
	fn add(ref self: Weight, capacity: Capacity, quantity: Quantity, amount: u128) {
	if self.entity_id == 0 {
	return;
	};
	if capacity.is_capped() {
	self.value += amount;
	capacity.assert_can_carry(quantity, self);
	};
	}
	}

With regard to SpeedConfig, we will have to stop storing ArrivalTime and instead store the start time of a journey so that we can always calculate the arrival time on the fly by multiplying an entity's speed with the distance of journey

[EjembiEmmanuel]

@ponderingdemocritus can I work on this?

[credence0x]

@ponderingdemocritus i don't get the description. could you rephrase

[ponderingdemocritus]

When we use config values throughout the app, we often pull from the config model then hardcode the value into a model. We do this for `sec_per_km'. This means that if we change the config, all entities that existed in the past, now have the old config.

If we move to computing the config on the fly whenever it is used, it means that we can change the config model, and every entity value changes.

[credence0x]

oh i see

[credence0x]

@EjembiEmmanuel i can walk you through it if you're willing to work on it asap

[Dprof-in-tech]

@EjembiEmmanuel i can walk you through it if you're willing to work on it asap

I am willing to work on this though if he's not available

[EjembiEmmanuel]

@credence0x yes, you can I'm available to work on it.

[credence0x]

@EjembiEmmanuel i can walk you through it if you're willing to work on it asap

I am willing to work on this though if he's not available

seems he is. is there any other issue you'd like to take? @Dprof-in-tech

[credence0x]

@credence0x yes, you can I'm available to work on it.

@EjembiEmmanuel pls text me on discord. @credence0x

[EjembiEmmanuel]

@credence0x I've sent you a friend request on Discord

[credence0x]

@ponderingdemocritus i can only see this issue with CapacityConfig and SpeedConfig. others seem to be computed on the fly. please confirm

[ponderingdemocritus]

yes - just do those

[edisontim]

Is this done or should I work on this?