Page 4 of 8

Re: Development Update #16: April 2014

Posted: Thu May 01, 2014 10:05 pm
by Skyfligher
Is there a torrent for this month's update? It would be great to see it in all it's glory! :D

Re: Development Update #16: April 2014

Posted: Thu May 01, 2014 10:28 pm
by JoshParnell

Re: Development Update #16: April 2014

Posted: Thu May 01, 2014 10:34 pm
by Katawa
magnet
Spoiler:      SHOW
magnet:?xt=urn:btih:JBO24YJIKEKPNUX2XFU2N7HYNTYLYTL2&dn=April%202014%20Update%20HD.mp4&tr=udp%3a%2f%2ftracker.openbittorrent.com%3a80%2fannounce&tr=udp%3a%2f%2ftracker.publicbt.com%3a80%2fannounce&tr=udp%3a%2f%2ftracker.ccc.de%3a80%2fannounce

Re: Development Update #16: April 2014

Posted: Fri May 02, 2014 12:32 am
by XergesXSX
Feedback:

1. there is a dim blue light opposite the sun lighting up the asteroids. Earlier in this thread you might have said this is from the mining beams, but this is a good ambient light effect. It was so good I assumed it was intentional and not the beams doing it. I think in film/art this is called a back-light(?). It gives more visual appeal than objects having pure dark on one side (especially for a dark object on a dark background).

2. love the new station, asteroid shape tweaks.

3. what black magic allows one person to outdo Eve Online? :shock:

Re: Development Update #16: April 2014

Posted: Fri May 02, 2014 10:56 am
by Rabiator
JoshParnell wrote:
ThymineC wrote:
JoshParnell wrote:"Matched together" suggests that you either want to perform multiple actions in parallel with different units (which is equivalent to what already exists), or perform multiple actions in serial. Does it really make sense to do the latter, though?
I hope we can still serially chain relatively low-level actions, though, as in Command Stacking. This would be necessary if, as Flatfingers proposes, I wasn't able to maintain instantaneous communication with my subordinates, or if I wanted them to pull off some complex task without me having to constantly monitor them.
Yes, absolutely. But I consider this different from a project allocation - it is not a continuous high-level task, just a traditional series of commands. Definitely still something you can do :)
Can we do this as an infinite loop? As in
1) Mine mineral X (until cargo hold is full)
2) Transport (to...)
3) Give cargo to entity Y
4) GOTO 1)

That may be what ThymineC meant :think: .
In effect, it would be a somewhat more narrowly defined form of project:
The NPCs under your command would not just mine anything and sell it anywhere, but look for a specific resource and deliver the proceeds to a specific location (maybe one of your factories?). But they might still have some autonomy in finding the best asteroid field and the safest route.

Re: Development Update #16: April 2014

Posted: Fri May 02, 2014 11:01 am
by Talvieno
In an interface, that could be done with a simple "mine" command:

"Mine from [locationX] and carry contents to [locationY]", with a default of "whatever's best" for both. I'd hope that's how it would work anyway.

What would be more complex is "Mine from [locationX] and carry contents to [locationY], while attacking any [shipTypeA] that come within [DistanceB], if [combatRatingA] is less than [[combatRatingA] / [personalCombatRating]].

Or perhaps "Mine from [locationX] and carry contents to [locationY], while acting as a [patrolShipType] on the journey to (locationX)".

OR, perhaps "Mine from [locationX] and carry contents to [locationY], while sabotaging any ships of [FactionA] that are larger than [MassB] if [cargoFullnessPercentageC] is less than [cargoQuantityD]".

The list could go on for a while, and everything would have a useful situation where the default command just wouldn't cut it quite as well. Commands could potentially get ridiculously complex to the point that the player could feel like they're programming their own AI. The real question is, how complex do we want to go?

Re: Development Update #16: April 2014

Posted: Fri May 02, 2014 11:31 am
by Rabiator
I think the "mine" command needs at least three parameters to fill all obvious applications:
Mine [mineral X] from [location Y], carry contents to [location Z], with the prerequisite that [player corporation] has storage capacity in [location Z].
[Mineral X] and [location Y] could be replaced by "any", and [location Z] could be omitted, in which case the ship would just fill up its cargo hold with ore and wait for new commands.

That's already semi-complicated for a fairly simple task. For more complex tasks, the parameter list may become a bit unwieldy. That's why ThymineC and me suggested chaining commands. Which may feel like programming one's own AI, but work instructions in real life can be just as complex. Hmm, how do we avoid writing ten-page work instructions in LT? :think:

Re: Development Update #16: April 2014

Posted: Fri May 02, 2014 11:35 am
by ThymineC
Rabiator wrote:Hmm, how do we avoid writing ten-page work instructions in LT? :think:
For repeating low-level serial tasks.

For one-off low-level serial tasks.

I guess.

Re: Development Update #16: April 2014

Posted: Fri May 02, 2014 12:22 pm
by Rabiator
I like the pipeline idea, and it is not so much different from X3 factory complexes. Only that pipelines can be distributed over space where the factories in a X3 complex must all be directly connected. Nice abstraction of goods transport here :) .
Cornflakes also suggested some upper and lower bounds for selling to and buying from 3rd parties. I approve of that, a detail that is missing in X3 :thumbup:

Re: Development Update #16: April 2014

Posted: Fri May 02, 2014 3:54 pm
by ThymineC
Just finished watching the torrent version.

I really like the new look of the boost capacitor. :thumbup: It's stylistically simpler and fits the feel of LT better I think. I recommended to change the style here, and I like the one in the video better than the example I gave.

I like the old font better, though.

Re: Development Update #16: April 2014

Posted: Fri May 02, 2014 6:31 pm
by 5anitybane
ThymineC wrote:I like the old font better, though.
Oh? I quite like this new font, the older one seemed like fonts I've seen before, whereas the new one seemed more crisp (text AA?), and cleaner in design.

Re: Development Update #16: April 2014

Posted: Sat May 03, 2014 10:48 am
by TONES
5anitybane wrote:
I quite like this new font ...
+1
back to lurking

Re: Development Update #16: April 2014

Posted: Sat May 03, 2014 11:20 am
by Commander McLane
Shiny and interesting update. Like others noted, I'm finding the rapid going through the menus distracting, and not only in this month's update, but in the last few updates as well. I can't follow it, and a lot seems to be just going back and forth through the menu structure purely for the heck of it, serving no purpose whatsoever. It looks more like a nervous tic than like presenting a feature. I'd be glad if you could tone it down drastically for the following updates.

And I have one question. If you've explained it in the video I must have missed it: what are the green/red bars that are plotted above the ships? Please, please don't let them be "NPC life energy bars". I hate those with a passion. They're screaming ARCADE GAME in my face, and nothing of the sort should have a place in a space sim. So I really, really hope that they're just a debugging feature that will be removed by default from the final game.

Re: Development Update #16: April 2014

Posted: Sat May 03, 2014 11:24 am
by Talvieno
Commander McLane wrote:=And I have one question. If you've explained it in the video I must have missed it: what are the green/red bars that are plotted above the ships? Please, please don't let them be "NPC life energy bars". I hate those with a passion. They're screaming ARCADE GAME in my face, and nothing of the sort should have a place in a space sim. So I really, really hope that they're just a debugging feature that will be removed by default from the final game.
I have a feeling you won't be pleased about it, but I'm almost positive they're HP bars. You can see some of them begin to turn red when the associated ships take damage.

Re: Development Update #16: April 2014

Posted: Sat May 03, 2014 2:32 pm
by Flatfingers
I liked how the Limit Theory Prototype (LTP) handled this.

It could be a little hard to see unless you knew to look for it, but my recollection is that in the LTP "ship health" info was a circle on the HUD projected around the targeted ship that turned dark as the target ship took damage.

Bearing in mind that it's useful to a human player to see how much damage is being done to a target ship's shields and armor, would changing the display to look more like LTP's style make this any more palatable? Or is a less game-y and more diegetic representation of damage (such as increasingly violent explosion graphics) required?

How should NPCs know when their targeted ship is being damaged?