Sounds like a job for ship editors (polyline or bezier with endpoints snapping to edges of room squares).John Luke Pack Hard wrote:I believe the correct philosophy here is to give the tools to the modders to make the mod good
Somewhere, there needs to be a tool to either make the tunnel or draw it manually. FTL - as it is - can't fully support that functionality.
[MOD][WIP] FTL: Overdrive
-
- Posts: 792
- Joined: Thu Oct 25, 2012 12:01 pm
Re: [MOD][WIP] FTL: Overdrive
-
- Posts: 112
- Joined: Thu Nov 15, 2012 8:45 am
Re: [MOD][WIP] FTL: Overdrive
Vhati wrote:Sounds like a job for ship editors (polyline or bezier with endpoints snapping to edges of room squares).
I'll write that down.
-
- Posts: 792
- Joined: Thu Oct 25, 2012 12:01 pm
Re: [MOD][WIP] FTL: Overdrive
John Luke Pack Hard wrote:the background image will be completely covered by the foreground rooms.
Oh, you want an overlay layer to draw schematic lines across all the rooms, not corridors that weave around them.
Adding a static image layer to the engine with togglable visibility wouldn't be too problematic if it doesn't clutter the GUI/hotkeys. Better make that button disabled/hidden when the image isn't provided.
-
- Posts: 112
- Joined: Thu Nov 15, 2012 8:45 am
Re: [MOD][WIP] FTL: Overdrive
Vhati wrote:Oh, you want an overlay layer to draw schematic lines across all the rooms, not corridors that weave around them.
Adding a static image layer to the engine with togglable visibility wouldn't be too problematic if it doesn't clutter the GUI/hotkeys. Better make that button disabled/hidden when the image isn't provided.
For this purpose I believe it would be better if we bind this overlay image to the ship class - non-static of course.
-
- Posts: 792
- Joined: Thu Oct 25, 2012 12:01 pm
Re: [MOD][WIP] FTL: Overdrive
John Luke Pack Hard wrote:Vhati wrote:Adding a static image layer to the engine with togglable visibility wouldn't be too problematic if it doesn't clutter the GUI/hotkeys. Better make that button disabled/hidden when the image isn't provided.
For this purpose I believe it would be better if we bind this overlay image to the ship class - non-static of course.
Yeah, an optional attribute to set the image when a mod defines the ship.
By static, I meant image-file based, as opposed to dynamically generated by the engine with code.
An animated overlay is still doable I guess. Obviously not a static member of a java class.
-
- Posts: 792
- Joined: Thu Oct 25, 2012 12:01 pm
Re: [MOD][WIP] FTL: Overdrive
Can you have several of those, like in Swing's JLayeredpane?DiEvAl wrote:I think you are talking about TWL's <overlay> tag. It specifies an image that's drawn on top of all child widgets.
Or is that tag unique, like the top layer, known as the glass pane?
If unique, and if widgets can just be drawn anywhere to overlap, specifically tying the door schematic to one of the background widgets seems inconsistent (though not necessarily wrong), when you're also doing floors, room decoration, fires, crew, etc, each successively higher, in between the hull and schematic. *shrug*
-
- Posts: 4
- Joined: Sun Jun 09, 2013 4:42 pm
Re: [MOD][WIP] FTL: Overdrive
Apologies for not reading through all 32 pages, but would custom systems/subsystems, custom resources and a more easily editable GUI for various things (store, resources, systems etc.) be a thing?
-
- Posts: 792
- Joined: Thu Oct 25, 2012 12:01 pm
Re: [MOD][WIP] FTL: Overdrive
I'm playing around with a store to get the hang of themes, and designing classes in the style of DiEvAl's ship demo. Not sure yet if I'll end up commiting or discarding it as an exercise...
-
- Posts: 792
- Joined: Thu Oct 25, 2012 12:01 pm
Re: [MOD][WIP] FTL: Overdrive
Dalvik bytecode != Java bytecode...DiEvAl wrote:There are a bunch of other scripting languages with good java integration around though. Consider groovy, jruby or jython for starters.
-- Jython doesn't work on Android.
-- Neither does JRuby.
-- Nor Groovy. Addressing that is one of the ideas for the 2013 Google Summer of Code.
-- When Scala 2.11 comes out, it should be capable of evaluating scripts without compiling first (JSR223 spec). Maybe?
-- Oracle's runtime comes with a JavaScript interpreter (Mozilla's Rhino), which isn't guranteed to exist everywhere. Dunno about Android. StackOverflow has code to list available interpreters on a system, and links to a JSR223 primer demoing JavaScript.
-- Edit (2013-09-01): BeanShell is viable: embeddable live scripts without going through a bytecode phase.
Last edited by Vhati on Sun Sep 01, 2013 2:08 pm, edited 2 times in total.
-
- Posts: 792
- Joined: Thu Oct 25, 2012 12:01 pm
Re: [MOD][WIP] FTL: Overdrive
Vhati wrote:I'm playing around with a store to get the hang of themes, and designing classes in the style of DiEvAl's ship demo. Not sure yet if I'll end up commiting or discarding it as an exercise...
Stores can sell several different things.
Crew, Augments, (Sub)systems, Weapons, and Drones
There are separate blueprint classes with various attributes. That's a given.
I made StoreShelfItemInfo with standard attributes (icon, description, price). Then subclasses constructed using instances of each blueprint to set those values (StoreShelfCrewInfo sets a "Bob" as its description, etc).
TWL widget+theme pairs render store shelves of each type: Augment renderer for 3 bars, Weapon renderer for squares.
The problem then is how to associate blueprints, store info subclasses, and GUI widgets together.
How flexible should this be?
- Hardcoded if/else blocks are straightforward but rigid.
- A centralized class lookup table would allow code to register new mappings or clobber existing ones (e.g., to change GUI widgets). StoreShelfItemInfo subclasses would each have a buy(gameState) method to manipulate the ship (spawning a crewmember, etc).
Abstracting blueprints and looking em up doesn't seem so bad, but handling mystery classes in general might get hairy: {spawned thing} occupying a room square checks if {other thing} nearby implements the FriendOrFoe interface, then calls isHostile(), then checks for Damagable interface, then calls addDamage(amt, type, srcObj), etc. We could restrict spawnables to specific classes (and their subclasses) to mitigate that however.