Pleb wrote:Have also theorised about multiple start locations, but struggling to figure out a way of setting a variable in one file and recalling it in another - for example, in a file called PlayerEntityControl.m (I think, again at work so can't check!) the commands at the start of the game could be modified so that when you start, press N to start a new game and then press Space, you could change it so that instead of pressing Space you press 1, 2 or 3 to select different starting locations, which could also have different ships, money and legal status. However, the set up for the starting game is contained in the file PlayerEntity.m so you would need to set a variable in PlayerEntityControl.m that could be read in PlayerEntity.m in order to do this. It is possible though, I'm sure...
If you look carefully at the order things happen in, then it's not what it looks like to the player, so this is a bit easier.
Firstly, the game loads the new game in PlayerEntity. (Look at the worldscript loading in the log, for instance) Then, it displays the spinning cobra and start screen, with PlayerEntityControls handling load/save. If the player chooses to load a saved game, it takes them to the load screen. If they then exit that screen without loading a saved game, it drops them back into the new Jameson loaded at game start.
So, to have alternative starting positions, all you need to do is:
1) Hack together some save-games for those starting positions. Easy enough to do either by editing the save file or by modifying the startup in Player Entity and saving the result.
2) Modify the startup screen in PlayerEntityControls so that if they choose not to load a saved commander, the new commander screen with the ship previews offers them choices. If they pick something other than '1', load the saved game you prepared earlier.
(Or just distribute the savegames from step 1 and don't bother changing the source code, but where's the fun in that
)
On this bit specifically:
Pleb wrote:but struggling to figure out a way of setting a variable in one file and recalling it in another
It's an OO language, so you (in general) don't do this as such. Instead, you use properties and method calls on objects. So, there is for instance exactly one Player object. You can access it globally as the PLAYER variable, but if you're in a method definition in one of the PlayerEntity files it's the local object.
So, for instance, you can do
[PLAYER setForwardShieldLevel:newLevel] from any function in any file to set the player's forward shield to
newLevel, where
newLevel is a variable calculated locally in this file.
Or each Ship is a ShipEntity object (the PLAYER object is also a ShipEntity object, but overrides some of its methods and adds some new methods and properties {1}). So you can get the ShipEntity reference for a particular ship in various ways, and then call methods on it to either set or retrieve information, or to cause it to perform more complex behaviour.
Code: Select all
ShipEntity *ship = [UNIVERSE spawnShipWithRole:@"pirate" near:PLAYER]; // adds a random pirate ship near the player. UNIVERSE is the other important global object.
[ship becomeExplosion]; // and then blows them up
This, rather than having a variable which is directly read by two different objects, is how it's supposed to be done: find the object you want, then call methods on it to get or set variables, or do other things.
{1} And the ShipEntity object is also a subclass of the Entity object, so both ShipEntity and PlayerEntity get all the methods and properties an Entity has. PlanetEntity is also a subclass of Entity, so gets the methods Entity has, but is not a subclass of ShipEntity, so you can't do
[planet becomeExplosion] (unless you first write a
becomeExplosion method in PlanetEntity.m, of course)
Does this make it a bit clearer how things are structured in the source?
) with the way the systems are generated from the galaxy seed...![[EliteWiki]](/images/elitewikismall.png){kind=small}
GalCop Rewards
