Astro Future

Just out of curiousity.. I was wondering, what the future is for Astrosynthesis.
Is Ed updating the program again in the future?? Possibly with more features?

Just a random question from a frequent user of the program.. and I'm sure many other users would be interested as well to know what the plan is =)

Peace
Nax

Comments

  • edited September 2012
    That's something I'd like to know too.
    At present, there are things I love about AS and things I don't. With some of the projects I'm working on, I've seem to hit the limits of the program.

    What I'd like to see:
    1) Better handling of very large sectors. Working with a sector with over 100,000 stars with children can kill the program. I find it laughable that you can't move the slider in the generator for the number of systems very far to the right.
    2) More control in the API for generating systems. I want to make Earth analogs, not what AS defines as "hospitable".
    3) A 3D front end that looks and acts more like Celestia. Stars, planets, and moons (all children in fact) all in the same 3D view.

    This may asking too much from NBOS, but AS is a great program and can be better.
  • 2) More control in the API for generating systems. I want to make Earth analogs, not what AS defines as "hospitable".

    I´d like to be able to define what AS calls "hospitable". Ideally, I´d like to define my own categories, such as "Terran", "Near-Terran" and "Marginal".
  • Naximan wrote:
    Just out of curiousity.. I was wondering, what the future is for Astrosynthesis.
    Is Ed updating the program again in the future?? Possibly with more features?

    Yes, there will a new version... but it will be a while (several years), as I'm now working on upgrading other products in the line (The Keep, then FM, etc).
  • That's something I'd like to know too.
    1) Better handling of very large sectors. Working with a sector with over 100,000 stars with children can kill the program. I find it laughable that you can't move the slider in the generator for the number of systems very far to the right.
    Far to the right would make the sectors extremely dense. Do you mean to the left? have you tried the update here:
    http://www.nbos.com/nox/index.php?action=1001&id=413
    This makes the lower end of the density slider much less dense.
    3) A 3D front end that looks and acts more like Celestia. Stars, planets, and moons (all children in fact) all in the same 3D view.
    Thats not the goal of Astro. Celestia is a great program, buts its a simulator. Astro isn attempting to be a simulator, its a map maker. Showing everything at native scale wouldnt be very good for that purpose. What you may want to do is look into making an exporter to Celstia.
  • Chaos wrote:
    I´d like to be able to define what AS calls "hospitable". Ideally, I´d like to define my own categories, such as "Terran", "Near-Terran" and "Marginal".

    You can do something like this now. Set a sector wide system data field (Sector -> Properties -> System Data Fields in the menu) called 'Environment' for all terrestrial planets. In a script, cycle through every body, and assign a custom field named 'environment' with one of those values to each terrestrial body based on your own criteria. Then hide the Habitability field in the system data dispaly.

    You can even search on your custom field. The System Data fields are a very powerful feature.
  • Thanks for your replies Ed =)

    It's good to know that you plan on updating Astro sometime in the future, even if it does takes a long time.
    Any thoughts on what new features/changes you are planning for the future update for us to look forward too?

    Thanks again

    Nax
  • Ed_NBOS wrote:
    That's something I'd like to know too.
    1) Better handling of very large sectors. Working with a sector with over 100,000 stars with children can kill the program. I find it laughable that you can't move the slider in the generator for the number of systems very far to the right.
    Far to the right would make the sectors extremely dense. Do you mean to the left? have you tried the update here:
    http://www.nbos.com/nox/index.php?action=1001&id=413
    This makes the lower end of the density slider much less dense.
    3) A 3D front end that looks and acts more like Celestia. Stars, planets, and moons (all children in fact) all in the same 3D view.
    Thats not the goal of Astro. Celestia is a great program, buts its a simulator. Astro isn attempting to be a simulator, its a map maker. Showing everything at native scale wouldnt be very good for that purpose. What you may want to do is look into making an exporter to Celstia.

    For the slider: No, I mean right. I was wondering, why have a slider setting that the program can't handle? Generate a 1000lyr cube, slider all the way to the right, and with star and child generation on and see if the program can handle it (or even complete the task).

    If it's trying to be a simulator, then why is there a system view that does just that? If its just a map maker, then does it store so much data that is unneeded for a map? Why does a map need to know the date? Atmosphere? Density?

    And as for your canned "a script can do that" response to everything; Great, then give us better documentation and examples so we can.

    Ed, we love this program and just want it to be greater.
  • For the slider: No, I mean right. I was wondering, why have a slider setting that the program can't handle? Generate a 1000lyr cube, slider all the way to the right, and with star and child generation on and see if the program can handle it (or even complete the task).

    Heh... good luck with THAT. I think the highest density setting is something like .5 parent objects per cubic light-year, i.e. you´d be looking at around half a billion star systems. The lowest density setting, by the way, gives you around 0.005 parent objects per cubic light-year, more or less like our neck of the galaxy.
    If it's trying to be a simulator, then why is there a system view that does just that? If its just a map maker, then does it store so much data that is unneeded for a map? Why does a map need to know the date? Atmosphere? Density?

    A lot of this data, including the existing system view, serves two purposes: facilitating the task of visualizing travel from A to B, and telling you what can expect to encounter at either A or B. I wouldn´t want to miss any of it.
    And as for your canned "a script can do that" response to everything; Great, then give us better documentation and examples so we can.

    I second the suggestion of improved script documentation or even a Script 101. As it stands, writing even a simple script is prohibitively difficult for anyone without programming experience - unlike writing an Inspiration Pad generator, for example.
    Ed, we love this program and just want it to be greater.

    On that we also agree.
  • For the slider: No, I mean right. I was wondering, why have a slider setting that the program can't handle? Generate a 1000lyr cube, slider all the way to the right, and with star and child generation on and see if the program can handle it (or even complete the task).

    Its not really an issue of the program 'handling' it. I've made 10GB+ sectors. I'm not sure how much bigger you want the program to manage. I'm not going to artificially limit sector sizes because there is no hard and fast actual limit (other than 2 billion systems, and 16TB file sizes).
    If it's trying to be a simulator, then why is there a system view that does just that? If its just a map maker, then does it store so much data that is unneeded for a map? Why does a map need to know the date? Atmosphere? Density?
    It doesnt show the system at scale. In the star system view, the planets are shown at 10x their size (or maybe 100x) so you can actually see them relative to the distances involved. The data is there because its encyclopedic data. In a planetary view, the sizes are less distorted, but stations and others are still shown at exagerated sizes.
    And as for your canned "a script can do that" response to everything; Great, then give us better documentation and examples so we can.
    The other option to that response is to just say 'nope, cant do it'. But that wouldnt be accurate. 95% of the Astro 2 api still applies to v3. And there's a lot of examples of iterating bodies in scripts on nox.
  • Chaos wrote:
    I second the suggestion of improved script documentation or even a Script 101. As it stands, writing even a simple script is prohibitively difficult for anyone without programming experience - unlike writing an Inspiration Pad generator, for example.

    My thought is to remove the API all together in v4.0 and replace it with an expanded version of the Natural Language Search system. Something that would allow updating data as well as finding it. The current scripting API is difficult - it wasnt meant not to be. It directly accesses the classes and functions used by Astro under the hood, and Astro itself is a very complex application. Its far more complex than, say, the FM scripting API which doesnt have the nested data structures, load-as-needed storage system, and customizable data displays.
  • I agree!! This program isnt just brilliant... its revolutionary in its own right. There are so many possibilities with the program so far, but there can be so many different perks and features which could be added in to make it even more revolutionary.

    I personally would like to see more concentration on the graphics in the program. For example, for specific spectral classes, a 'yellow star' (much like the sun) would look like the sun would look (similar to as they do so far). Larger stars like blue giants would be blue when zoomed in, and red giants red.. but of course it doesnt have to end there.
    We could for example have the stars looking like this (maybe some animation which is global for all stars of this type): glowing-sun-prominence_6594_600x450.jpg

    This of course is what a blue giant could look like: blue%20giant.jpg


    Thats just for stars.
    For other objects like Nebulas, Id love to see them generate with stars inside them.. since nebulas are the birth ground of stars. Id love to see some randomised graphic for it too.. similar to how the gas giants are created.

    I hope i've made sense
  • edited October 2012
    Ed_NBOS wrote:
    And as for your canned "a script can do that" response to everything; Great, then give us better documentation and examples so we can.
    The other option to that response is to just say 'nope, cant do it'. But that wouldnt be accurate. 95% of the Astro 2 api still applies to v3. And there's a lot of examples of iterating bodies in scripts on nox.

    To be fair, the API documentation as it currently stands is pretty useless, which is why your "just write a script for it" response is never helpful. It lacks examples in a lot of places (and we need examples), and some terms even lack any explanation beyond what variable type they are.

    http://www.nbos.com/support/docs/AlienAPI/ for example (which is what I use for reference) has not been updated since 2006. I know that a lot of the questions I've asked about here were because I wasn't able to find answers there, and much of what I wanted to do has fallen by the wayside because I didn't get a useful response here.

    In future, instead of saying "write a script", I would suggest that you actually write an short example script in your reply that can at least give the user some idea of how to tackle the problem. At least explain what to do, even. Because right now, most times we just have no idea how to go about doing what we want to do and we're not going to get it from the API documents. It's one reason why I've largely given up on this program, because there is pretty much no useful support for it, and I know I don't have the time or the inclination to dig through an obtuse API to try and figure it out. And considering we paid $30+ for this program, that lack of support is a little disappointing to say the least.

    The request for better documentation is something that keeps coming up, and it keeps getting pushed aside. It's like you've only half-heartedly made the scripting option available and then expect us to figure everything out for ourselves without providing much in the way of help or guidelines or explanation, which is a pity since the actual manual for the game is pretty well written and helpful.
  • I second what EDG said.

    The scripting interface is a feature which is advertised as part of the game. It´s part of the decision each of us has made in favor of buying this game, and it´s part of what we paid for.

    And then we find out that, oops, the feature is well nigh useless for the majority of users, because you refuse to support it properly.
  • Right on, EDG and Chaos. I'm right there with you.

    I too have hit the end of AS's usefulness. Better and more scripting examples would go a long way to helping us discover this supposed "power feature" in AS.
  • I think that there are two type of people who buy AS - the first are the "casual users" who just use the random settings to quickly make their own universes, which doesn't really require much delving into the scripts or background. Casual users just use the program a few times without going 'under the hood' and then don't use it anymore once it serves their purpose. The other type are the "Power users" who want to make more detailed settings, or customise the output further, or map existing systems (which does require some degree of customisation and scripting). Power users need more support, but are also more likely to tell others about the utility of AS3.

    People like me - and I guess Chaos and brothercool and probably everyone else who has ever bothered to register on this board and ask questions here or on the scripting forum - are the 'Power Users' that bought AS... and we're getting no support at all. The net result is that eventually we give up and you don't hear from us again because we don't want to use the program anymore. And there isn't enough of a 'critical mass of users' on this board for more experienced people to help eachother out, because they've all gone off to do better things because they got no support for their own questions themselves. So if you're a power user, you're basically screwed.

    It's fine if you're a 'casual user' because they don't require much in the way of support (and the manual is good enough for them) - but power users need to be warned about this lack of support, most likely in a review on the sites where people buy the program. If that costs NBOS a few sales, then they only have themselves to blame.

    EDIT: And I have written a review, and gave the program 2 stars out of 5. http://rpg.drivethrustuff.com/product_r ... s_id=95347
  • Let´s say that I would be a power user if the scripting was more accessible. As it is, I´ll continue to be a casual user whenever there´s something I can use AS3 for without having to study Computer Science first.

    Good review, by the way. I´d have rated it 4 out of 5 for basic/casual users, though, because those parts of AS3 that are accessible to them are pretty darn cool.

Leave a Comment