Flux Classes

Ahhh, so your "layer" is actually a package (for organization's sake).

And when you save, you call all the related "layer functions" for each station, which associate the data to the station through serial numbers.

And I assume that when you load, you call those related "layer functions" that load all the saved data back into the station objects. Right?

And those "layers" are only for the storing and retrieval of data. Then your associated "rules layers" are called when you need to actually work with the data in-game. Is this correct?

Lol, did I just basically repeat everything you just said? []

*edit*
I understand that you make the rules a seperate package because of it. But what is the circular linking limitation?

mailto:second_chance@cox.net
The Ultimate Guide To Modding: I-War 2 - Edge Of Chaos (on hold during SW MP mod)
cartoons.sev.com.au/index.php?catid=4
.

A bunch more details on circular linking here:

www.i-war2.com/forum/topic.asp?w ... D=634#9786

The short story is the problem exists when two packages need to refer to each other. In the object world, it would be easy for a station to have a faction object attached. And a faction object could maintain a list of stations that it owns. But in the POG world, these two pog packages cannot refer to each other, or the linker locks up at run time. Station.pkg tries to load Faction.pkg forcing Faction.pkg to try and load Station.pkg, which is not yet loaded. This goes on forever.

And when you save, you call all the related "layer functions" for each station, which associate the data to the station through serial numbers.

Yes. Because we cannot allocate memory, except to create objects and attach properties to them. Stations are a unique example, because they already have an in game representation. But an AI planner (built using an unplaced waypoint) would use all the same layers. So would an underworld base, a faction, a politician, an agent, etc. You can think of the save call as replacing "Object.SerializeSelf();"

So, esentially, this would make distructable stations that would have side affects?

Yes, this design was to make side effects of destroying stations (or ships, or whatnot) easier to code.

And it makes writing an AI planner easier, because moving stuff around the "gameboard" objects becomes much more straight forward. Every object "inherits" the same properties and functions from the layer.

Another concept that is useful is the "PlayerArrives" function. An object can register itself on a station (by register I mean attached into a list property of the station) and when the player gets close to the station a PlayerWatch loop calls all the PlayerArrives functions on the station. Those player arrives functions look into list of stored objects and wake each one up.

Say, for example, the object is a Navy Task Force. When "woken" it creates a command ship. Then it look at the number of fleets it has stored and creates a bunch of patrol ships to represent them. Then it looks at the number of supplies it has, and creates supply ships to represent them. From a player point of view, the whole task force has always existed at the station. But from a game point of view, it is just one unplaced waypoint object. Which makes moving a navy task force as easy as unregistering it from one station, and registering it at another.

This PlayerArrives pattern makes it possible to place thousands of items in the game, but not actually create any physical items until the player arrives. (It is how I wish culling worked in Flux).

-Gtrout

Say, for example, the object is a Navy Task Force. When "woken" it creates a command ship. Then it look at the number of fleets it has stored and creates a bunch of patrol ships to represent them. Then it looks at the number of supplies it has, and creates supply ships to represent them. From a player point of view, the whole task force has always existed at the station. But from a game point of view, it is just one unplaced waypoint object. Which makes moving a navy task force as easy as unregistering it from one station, and registering it at another.

[:0] Holy crap, that's brilliant!

I'm fantasizing about what other insanely cool tricks you've figured out while coding epic.

mailto:second_chance@cox.net
The Ultimate Guide To Modding: I-War 2 - Edge Of Chaos (on hold during SW MP mod)
cartoons.sev.com.au/index.php?catid=4
.