Subset Games Forum

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.

Sounds like a job for ship editors (polyline or bezier with endpoints snapping to edges of room squares).

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.

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.

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.

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.

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.

Can you have several of those, like in Swing's JLayeredpane?

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*

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?

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...

DiEvAl wrote:There are a bunch of other scripting languages with good java integration around though. Consider groovy, jruby or jython for starters.

Dalvik bytecode != Java bytecode...
-- 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.

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).

TWL can be coaxed into adding new subthemes (use ref="*" within the store window's theme, and include toplevel files for each shelf-type made findable with allowWildcard="true") but only with unique names, no replacement. A widget determines layout, so it's pretty much tied to a specific theme. So to mod appearance beyond simple image swapping would mean changing both the theme name and Widget class used. I don't know how that could be done without a registry.

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.