Page 36 of 38

Re: [MOD][WIP] FTL: Overdrive

Posted: Thu Oct 03, 2013 5:17 pm
by kartoFlane
Well, all I thought of was covered by the book excerpt.

Kryo/Kryonet certainly looks promising... But I can't really say much else since I have no networking experience whatsoever :X It does seem to be solving most of the issues outlined in the chapter...

Regarding the code, some things I felt capable of tackling myself seem to require much more groundwork to be laid down first -- like scripts (needs the game to actually supply some sort of API for the scripts to work with), or /data/ loading (needs the actual classes that will use the data).

I'll try to do something in the model / game object department over the weekend *shrug*
Something like being able to create an instance of a model, and getting it to show on test screen.

Also, a thing occured to me while playing around with the packer -- every time a new mod is installed/uninstalled, the resources will have to be repacked.
Unless we'll have a "mod compiler" that'll pack mods before they're distributed. Then a new manager would have to implement the functionality to add/append/overwrite those files...

It appears to me that no matter what, replacing textures will not be as easy as it is now.

Re: [MOD][WIP] FTL: Overdrive

Posted: Sun Oct 06, 2013 6:06 pm
by Vhati
I've sort of worked out a revised plan for events...

Code: Select all

// Create a new ShipModel.
int shipRefId = context.getNetManager.requestNewRefId();

ShipCreationEvent newShipEvent = Pools.get( ShipCreationEvent.class ).obtain();
newShipEvent.init( shipRefId, "Kestrel" );
context.getScreenEventManager.postDelayedEvent( newShipEvent );


// Make it the player ship.
int gameRefId = context.getGameModelId();

GameSetPlayerShipEvent setShipEvent = Pools.get( GameSetPlayerShipEvent.class ).obtain();
setShipEvent.init( gameRefId, shipRefId );
context.getScreenEventManager.postDelayedEvent( setShipEvent );


// Damage its hull.
ShipIntPropertyEvent propEvent = Pools.get( ShipIntPropertyEvent.class ).obtain();
propEvent.init( shipRefId, ShipIntPropertyEvent.INCREMENT, "Hull", -20 );
context.getScreenEventManager.postDelayedEvent( propEvent );


// Lookup an existing object by its reference id.
GameModel gameModel = context.getReferenceManager().getObject( gameRefId, GameModel.class );

Events are posted to an outbound queue where veto listeners can cancel any action they don't like (undamageable ship). Any events that make it through are shipped to the server via serialization. The server ships the events back (in the order received) to each player's inbound queue.

Then as events exit the inbound queue, a handler performs the described action to modify the models. Then the event gets forwarded to after-the-fact listeners like UI elements (instead of the direct observer strategy).


Still working on implementing all that.
For saving the game, refIds should make serializing the model tree painless. Saving the state of scripts and UI is still up in the air, however. Supposedly BeanShell objects can be serialized (or their NameSpace? or their Interpreter?) but I haven't succeeded at that yet.

Re: [MOD][WIP] FTL: Overdrive

Posted: Sun Oct 13, 2013 6:37 am
by Vhati
.
This is applicable to all engines.


Proposal to Decouple Rooms and Systems

From John Luke Pack Hard's compilation of requested features:
  • One system in a room, with multiple stations for multi-manned bonuses.
  • Multiple systems in a room, each with different stations.
  • One system spanning multiple rooms, in either of the above scenarios.
  • Tetris-like non-rectangular rooms (affects system icon location).

How to accomodate that...
  • Make stations independently placeable on squares in the ship (without blocking the square).
  • A dummy-station would be invisible and auto-manned, but placed anyhow.
  • Each station would be associated with a system; and each system with one or more stations.
  • Each station's system icon would be rendered on the station's square. Not great from a usability standpoint, since crew would often obscure it... but traditional icon placement could still be used for rectangular rooms with one station.

    If necessary, another requested feature "Ship foreground image" could help (I think referring to a togglable overlay to bring up as a reference diagram for things like teleport door pairs). Cover the area with a picture of an empty room with just the icon.

Damage dealing will have to account for deciding what systems to affect when a room is hit (likely all systems with stations present in that room; with the normal fixed amount of damage, regardless of how many stations or direct hits).

Same for repair (all systems, albeit one at a time, like with breaches and fires).

A system spanning multiple rooms could be repaired or damaged in two places at once for greater effect.

When multiple personnel sabotage/repair, the standard behavior of just standing somewhere in the room should be okay. No need to huddle around the station.

Re: [MOD][WIP] FTL: Overdrive

Posted: Fri Oct 18, 2013 6:49 am
by Vhati
Vhati wrote:Make stations independently placeable on squares in the ship (without blocking the square).

*Was imagining "img/ship/interior/computer1.png"*
computer1.png


*Codes a hull*
*Codes floor tiles*
*Codes floor lines*
*Codes pentomino-friendly wall borders*
*Codes room decorations*
...
Grr. Most station graphics are embedded in the decoration (and their glows are room-sized).
room_engines.png

Should've seen that coming.

Okay, well, stations can still be distinct objects for game mechanics, but this means the UI will need to represent both:
  • Single-square placeable, rotatable terminal + glows.
  • No visible terminal (decor-implies one). Just room-sized glows triggered by manning.

Re: [MOD][WIP] FTL: Overdrive

Posted: Fri Oct 18, 2013 10:04 am
by UltraMantis
Just a quick heads up. Cloaking room also uses a glow image. It's hardly noticable but it's used when the ship cloaks.
It's actually pretty cool. :)

Re: [MOD][WIP] FTL: Overdrive

Posted: Fri Oct 18, 2013 9:16 pm
by maharito
I stopped playing FTL for a while, but I pick it up again from time to time. Projects like this one give me hope that FTL will remain relevant and its community vibrant for many years to come. Cheers to your hard work so far, and thank you!

Re: [MOD][WIP] FTL: Overdrive

Posted: Sat Oct 19, 2013 12:07 am
by Kieve
UltraMantis wrote:Just a quick heads up. Cloaking room also uses a glow image. It's hardly noticable but it's used when the ship cloaks.
It's actually pretty cool. :)


...This gives me a potentially brilliant idea...

Re: [MOD][WIP] FTL: Overdrive

Posted: Sat Oct 19, 2013 7:55 am
by marksteele
g'day all, super old user here.

Just wanted to say its great to see this project still going on in some form. Also if I may suggest, it might be better to form overdrive gdx into it's own thread for the sake of clarity.

Re: [MOD][WIP] FTL: Overdrive

Posted: Sat Oct 19, 2013 8:11 am
by UltraMantis
marksteele \o/

Very nice to see you again!

Re: [MOD][WIP] FTL: Overdrive

Posted: Mon Oct 28, 2013 11:12 am
by codyfun123
marksteele wrote:Also if I may suggest, it might be better to form overdrive gdx into it's own thread for the sake of clarity.

I would agree with this. It would be nice for Vhati's Overdrive to have its own thread, given that the original owner of this thread is MIA.
Plus, it would provide a much better place for Vhati to present his progress. Having a topic thread and posting updates there would be perferable to posting them in someone else's thread.