Refactoring and renaming compounds based on Karthas077s work.

[jjonj]

Includes renaming of agent to compound and storage organelles (vacuoles) to be general storage instead of specialized. Minor refactoring elsewhere as was fitting (UI etc).

Changes from karthas version #82 include compiler error fixing, bugfixing, completion, renaming and re-designing.

[jjonj]

It works now! There's still some minor renaming and restructuring i would like to do before it should be merged.
Microbes will eventually stop being able to produce ATP in this branch as you eventually stock up 300 (the capacity of the three storage organelles combined) CO2 and unable to store ATP or eject the CO2. A system for ejecting some compounds will have to be worked out.

TODO:

• Change bandwidth to not be per operation but based on time, probably with a microbe member saying how much it can move until next update (calculated based on milliseconds) and make the bandwidth shared between all operation types. Fixed, but bandwidth was made per storage organelle and not for the entire microbe.
• Rename ejectCompounds to takeCompounds (cuz now im in control!!!) done
• Implement auto ejection of compounds when storage organelles get too filled and in general (based on discussion: http://thrivegame.forum-free.ca/t997p165-microbial-compounds-and-organelles).
  Pseudo-code idea:

For each vacuole  
    if more than or equal 80% filled then  
        add compounds to compound pool P until 80% full, lowest priority compounds first (sort?)  
    else  
        add compounds with priority 0 to pool P at some rate (bandwidth?)  
For each vacuole  
    if less than 80% filled then  
        absorb compounds from P until at 80%  
if P is non-empty then  
    eject contents of P from microbe  

The priority of a compound will be based on priority of process that uses it (new parameter to process organelles) and possibly how much is contained of the compound in the microbe vs how much the processes can use. Ties will be resolved randomly preferably.

I hate the complexity of my "algorithm" (lots of sorting and prioritizing) but considering the numbers it will be dealing with i guess it doesn't matter.

I am pushing the case of empty "hexes" also being able to store some amount of compounds to a future point in time, as i think this will depend on restructuring that will occur with the introduction of the microbe editor.

[jjonj]

Been working on a priority based system for expelling excess compounds but its getting overly complex and not transparent to the player at all. I'll try and think about it while in my exam period and seek feedback on the forum when i have something concrete.

[NickTheNick-zz]

Do you want us to discuss it on the forums?

On Sun, Jan 19, 2014 at 8:26 AM, jjonj notifications@github.com wrote:

Been working on a priority based system for expelling excess compounds but
its getting overly complex and not transparent to the player at all. I'll
try and think about it while in my exam period and seek feedback on the
forum when i have something concrete.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/91#issuecomment-32712201
.

[jjonj]

Ill fix up a quick demo of what i have now, explain it and we can have a discussion, I'll see if i can get it done tomorrow.
EDIT: Other stuff is taking priority atm

[jjonj]

I'm having some really wierd issues with ipairs refusing to iterate consistently. I have a table in hashmap style mode containing some information, but next(mytable) returns nil but if i double check table[keyIKnowIsThere] i get the correct value. I can do really ugly workarounds, but im really just confused

[jjonj]

Okay i did the ugly workarounds as temporary fixes.
I have a demo version ready for evaluation of the current compound sustaining system (keeping the right amount and the right type of compounds in the storage organelles). But it is very hard to understand whats going on currently, as all compounds have the same model. I will try to get some of the compound models included tomorrow (altough still without materials so they will all be orange) so that i can release the demo on the forums and get feedback.

[jjonj]

I'm not completely comfortable with the idea, but I am strongly considering merging this with master without review (as there seems noone here to do so atm). Some of the other issues I'm working on require the basic part of this branch, specifically the generalized compound storage, but the compound ejecting/threshold system is not in a finalized state, since the discussion on it hasn't settled and I don't know if it will be able settle to within a short timeframe or before more progress has been made. It would be possible to progress on the other issues without merging this, but it would be a lot more difficult that way.
The basic compound storage refactor and rename cannot be seperated from the ejecting/threshold part as one without the other leaves the game in a bad state.

So in summary, some non-final non-reviewed code may be merged with master, in the name of progress. Things can naturally be changed/fixed in the future.

[jjonj]

Details are currently being worked out in the forum discussion http://thrivegame.forum-free.ca/t1381-compound-system-implementation#29540 Quite a few parts of the compound system will be changed