Flux Classes

Possibly. But I'm sure that, given the sheer scale of Epic, they're probably working on something much more advanced than this. Thanks for the positive feeling though.

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
.

'they'? I think its time the EoC community organised! . On a large scale yes, what you are putting out is not nessearily revalent. However, on a small scale (i.e. fleets in-game) this sounds like it could be perfect for getting navy battles that are not just two swarms slamming into eachother. with some bugs bigger than others, which is what EoC fleet battles currently are.

oooo, i can not wait to make an anti-cap ship Navy Heavy Destroyer odf. Cutting beams and remote missiles way-hey!

Jwk...comander of =HEMP HUNGRY MONKEY=
www.i-war2.com/forum/topic.asp?TOPIC_ID=310

Cool! Glad someone else is working on a large system AI. Then I get a chance to play without knowing all the secrets!

Back to simulating persistant objects. Here are a few ideas I have tried. Not really meant to preach, but just to put them out there as something to think about.

There seems to be two ways to save an object from one play session to the next, you can use global variables, or you can use the State package, and let flux do it.

The only real disadvantage of using the state package is that you don't know precisely when all the states are restored. And that can make update functions tricky to write without bugs. But currently I am using states for mission tracking, because missions tend to need lots of unique properties, and they also need a task running all the time to keep watch over the player - so it is a good fit.

Most of the time I create globals to save information. One idea I wish I had right at the start: Every object that is going to get saved gets a unique ID number. This ID number added to the property name to save the object property.

We don't have inheritence in POG. But many things share common properties, such as current level of funds, or defense fleets, or owning faction, etc. So to get some of the advantages of inheritence I use "layers". A layer consists of the common properties (say "income" and "savings"), save and restore functions that will preserve just those properties, and the get and set functions to access them. This would be a funds layer. Every persistant object that used funds would use this layer. When the object as a whole needed saving it would call all of its layers to save themselves tFund.Save(current_station)

Not quite as good as objects, but better.

-Gtrout

Using serial numbers for the globals is pure genius. I'm glad I can just steal the idea without having to think it up myself.

Your idea of using layers sounds interesting, but I don't fully get it. What actually is the layer itself? And how does it store both properties and functions?. Could you elaborate further, I'm fascinated at the idea of bringing a custom type of inheritance to Flux.

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
.

Here is an example interface to a fleet layer package. What I needed it to do is store the number of fleets protecting a station (or other location) and the number of ship supplies stored there.

Adding the layers properties to an object works like this: Then to find out how many fleets are protecting a specific station:
fleet = tLFleet.GetFleets(station);

The power of the idea really gets clear when you want to do something more complex. Like say a station is destroyed, but you want to have the surviving ships flee back to a faction ship pool.

This code is nice and short because all objects use the same layer interface for storing fleets. So they talk to each other painlessly. A very similar 4 lines of code could move reinforcements between two stations, or from the faction to a station. The layers stack up quickly. Here is a chunk of the save code for stations:

This code loops through a list of stations saving each one. Most of the work is done by calling each layers save routine. All those "tLCenter.Save" kind of calls. Each layer knows how to save itself. They use the unique id value to insure no name collisions.

You can see the station layer has "inherited" the properties of tLProduction, tLMission, tLCenter, tLFleet, and tLRoot. These properties are now shared among all objects that use these layers.

Most of my layers implement only simple data storage. Then typically I add a Rules package of code that manipulates the information in the layer (such as tLFleetRules.pkg). Rules typically need to be seperate because of the circular linking limitation.

-Gtrout

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

Jwk...comander of =HEMP HUNGRY MONKEY=
www.i-war2.com/forum/topic.asp?TOPIC_ID=310