Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Categories
- 2.1K All Categories
- 200 Site Announcements
- 66 News and Announcements
- 134 General Discussion
- 836 Fractal Mapper
- 214 Fractal Mapper General
- 616 Maps and Symbols
- 32 Skwyre Virtual Table Top
- 29 Skwyre General Discussion
- 3 Skwyre How-To
- 361 AstroSynthesis
- 270 AstroSynthesis General
- 91 AstroSynthesis Plug-ins and Scripts
- 105 The Keep
- 105 The Keep General
- 59 ScreenMonkey General
- 18 ScreenMonkey Setup and Configuration
- 310 Inspiration Pad Pro
- 310 Inspiration Pad Pro General
- 135 NBOS Character Sheet Designer
- 135 Character Sheet Designer General
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
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
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.
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".
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).
http://www.nbos.com/nox/index.php?action=1001&id=413
This makes the lower end of the density slider much less dense.
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.
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.
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
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.
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.
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.
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.
On that we also agree.
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).
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.
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.
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 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):
This of course is what a blue giant could look like:
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
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.
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.
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.
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
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.