Page 1 of 1
cargo_import column in units.csv
Posted: Tue Feb 12, 2013 4:31 pm
by Andy
Hi everyone,
just a simple question:
What string/column/file determines whether the cargo_import given in units.csv works for a specific unit?
I had the idea to implement an ore harvesting option in PGG as it had already been discussed here in the forum. At first sight this seemed very easy to implement: adding the ore cargo to the cargo_import of an asteroid in units.csv and creating/implement the ore cargo to the game of course; maybe one hour of work alltogether. This way the ore should show up when the asteroid is destroyed; just like other cargo appears when a ship is destroyed.
Unfortunately it isn't that easy. No matter what I put to the cargo_import column of an asteroid it doesn't show up when the asteroid is destroyed. So there must be a switch somewhere that turns off this cargo_import functionality for specific units (as asteroids). Maybe it's the same that also switches off the targetability...
Hopefully someone can point me to the right direction.
Cheers,
Andy
Re: cargo_import column in units.csv
Posted: Tue Feb 12, 2013 5:14 pm
by klauss
AFAIK, what appears when it explodes is what is in Cargo. If you put something in Cargo_Imports, you have to wait for some NPC to dock with it and "sell" it some ore, which might not happen either quick enough or at all without tweaks to trading.py
Re: cargo_import column in units.csv
Posted: Tue Feb 12, 2013 6:20 pm
by Andy
You are right about bases and the trading, but cargo_import is also used for the ships and what appears when they are destraoyed (at least in PGG). I also tried the cargo column... no luck...
btw: 'cargo_import' is column DB, 'cargo' is column DC in PGG...
Re: cargo_import column in units.csv
Posted: Tue Feb 12, 2013 9:14 pm
by klauss
If you modified the right unit, it should work. Which unit did you add the items to?
Re: cargo_import column in units.csv
Posted: Tue Feb 12, 2013 11:01 pm
by Andy
I found something in universe.py:
Code: Select all
def systemCargoDemand (category,priceratio,quantratio,ships=1,planets=1):
i = VS.getUnitList()
un = i.current()
while (not un.isNull()):
if (un.isPlayerStarship()==-1):
isplanet = un.isPlanet()
if ( (isplanet and planets) or ((not isplanet) and ships)):
adjustUnitCargo(un,category,priceratio,quantratio)
i.advance()
un=i.current()
If I understand that correctly only ships and planets get cargo... (sorry, I've no clue on python code...)
Still the question remains how the engine 'knows' what a ship or a planet is....
Could these lines of code be modified to let all unit types get cargo?
Re: cargo_import column in units.csv
Posted: Wed Feb 13, 2013 4:07 am
by klauss
If you look carefully, "ships" means "not planets", so that would cover asteroids too. I think. You'd have to look for places where that function is called to see which parameters are sent.
Still... I don't think python scripts play a role here. Asteroid fields are created when loading the system file, in direct response to XML tags. That means python doesn't touch it, and "cargo_imports" then only affect what trading.py does later with the asteroid fields. But since asteroid fields aren't part of the dynamic universe dataset (AFAIK), then it's moot.
What matters then those ought to be "cargo", and what's there ought to be respected by the engine.
The trick, though, I think, is that units.csv has many entries for asteroids - there's the master "asteroid field" unit (not sure what its name is), that contains "asteroid group" subunits, which in turn contain a bunch of "asteroids". It's this last unit type the one you have to modify, identifiable because it won't have any subunits.
Except... except I found an interesting guard on the code preventing neutral units from dumping cargo. I guess that has to be fixed...
Re: cargo_import column in units.csv
Posted: Wed Feb 13, 2013 1:47 pm
by Andy
I understand how the asteroid fiels work. I gave the 'cargo' only to the single asteroids not to the master asteroid field and the asteroid groups... but no luck so far.
Code: Select all
Except... except I found an interesting guard on the code preventing neutral units from dumping cargo. I guess that has to be fixed...
Could you check that please? Maybe a workaround would be to set a fraction for the asteroids... Since they are passive it should make no difference whether they have a fraction or not...
Re: cargo_import column in units.csv
Posted: Wed Feb 13, 2013 4:01 pm
by klauss
I'm thinking two options, one allowing asteroids to dump cargo, and one allowing neutral units to dump cargo.
Re: cargo_import column in units.csv
Posted: Wed Feb 13, 2013 9:22 pm
by Andy
BREAKTROUGH!!!
You gave the essential hint: the faction.
I changed the faction of the asteroid field in the system file to 'pirates'. Now it works.
And btw, both columns in units.csv (cargo_import and cargo) work.
Nonetheless I'll use cargo import: there you can define a certain probability for the ore to appear. That also works nicely for ships and adds more variation...
So no code tweaking neccessary.
Thanks a lot!!!
Re: cargo_import column in units.csv
Posted: Wed Feb 13, 2013 9:27 pm
by loki1950
Should that be faction not fraction
darn English spelling never has been consistent.
Enjoy the Choice
Re: cargo_import column in units.csv
Posted: Thu Feb 14, 2013 12:39 am
by Andy
Sorry, I was so excited...
I correct it just in case somebody else reads it somewhen later...
Re: cargo_import column in units.csv
Posted: Sun Feb 17, 2013 9:30 pm
by Andy
Just to let you know: My idea of ore harvesting from asteroids works almost perfectly. The only problem that I have now is that sometimes ejected pilots appear when an asteroid is blown up... just like for blown up ships. I opened a new thread for this...
Thanks again for the help.
Re: cargo_import column in units.csv
Posted: Sun Feb 17, 2013 10:53 pm
by gonzo
Andy wrote:The only problem that I have now is that sometimes ejected pilots appear when an asteroid is blown up... just like for blown up ships.
Asteroidnauts!
Re: cargo_import column in units.csv
Posted: Mon Feb 18, 2013 4:17 am
by klauss
That's probably because the faction isn't the neutral faction.