|Terrain generation may change again in the next release. (I've mentioned why at the end of this post)|
Changes in R7a:
(See the 'Fixactis Releases' thread for the download links)
- It turns out that a good while ago I (At least I guess it was me ) broke the ability of GOES modules to set-target and engage the vimana or in-system drive. That's fixed now. (I only discovered it after I made a new GOES module, whose job is to hunt for felisian planets with fast rotation times - fndplnt, which is available as a curiousity)
- Me and BGreman discovered, while looking at the radiuses of various planets and moons in NIV and so forth, that the conversion factor for meters to centidyams cancels out of the temperature equations (to conclusively test, I set CentidyamsToMeters to 3.14159 and the temperatures came out the same still ). So I've removed the conversions from the equations, which makes them a little bit faster.
- The local targets info shows the radius of the target too now. That info popup looks a little squished with all that data, so maybe we should increase the size of the info popups and spread things back out a bit more again.
- Removed some debugging code which I had forgotten about (in the multiplayer and X stuff), which was preventing NIV from starting if c:\noctis didn't exist. Besides fixing a nasty crash bug, this might also speed things up a little.
- NIV now keeps track of the last known snapshot number. So now if you have lots of snapshots, taking new ones should be faster. But it won't EVER overwrite an existing snapshot. If you manage to take snapshot # 99999999, then when you try to take the next one, Noctis will check to see if there are any empty slots (e.g. if you had deleted an old snapshot), but if there aren't, then it will show a "TOO MANY SNAPSHOTS" message. Note: Normal snapshots are 64 KB and panoramic ones 180 KB, though if you have XP and have it set to compress the contents of your GALLERY folder, they'll probably (on average) take up only a third of the space that they would take up if uncompressed. (That is a rough estimate based on how much space my snapshots are taking up here) If uncompressed, 99999999 normal snapshots would take up about 5.96 terabytes of space (6103.5 gigabytes). If compressed to one-third of that size, they'd still fill up 2034.5 gigabytes...
- The palette stuff FINALLY (knock on wood) appears to be working properly - making it work right (without glitches) was more complex than I had expected. It might have been working before R7, but if so I broke it when I removed a 'flicker' effect whenever things were updated (like the sun position, etc). (The flicker effect is still gone, but I had to study the palette code and planet-surface-generation code to figure out WTF was going on - and I discovered several other bugs in the process)
- I've been attempting to fix it so that ground terrain won't change due to atmospheric conditions or nighttime. It looks like I've got it, though there MIGHT still be a problem there somewhere. If you see terrain suddenly change, unless you're on a very hot planet, it's a bug, please report it. Note: 'Albedo', which can cause a sector to be OCEAN instead of whatever it otherwise would be, was supposed to (I think) be the albedo of the surface only. The atmosphere and surface maps are merged prior to being displayed, and the albedo was calculated from the merged map. It looked like the albedo-calculating algorithm was supposed to remove the atmosphere albedo, the algorithm was flawed. I've reimplemented it (and simplified it too, really) by making the raw-albedo (that is, surface-only) be calculated while the surface is being drawn. Since raw albedo is only used when you're on a planet, and we already recalculate everything (including the surface and atmosphere and all that jazz) when you go down to the surface (or change sectors, etc), this works (the way Alex had this all implemented, it wouldn't have worked, because that stuff wasn't being recalculated when you went to a planet, it was using the previously calculated stuff for it).
- When you're in the stardrifter, the 'c' key toggles on and off the drifter's fancy new cloud-filter. If it's on, the drifter filters out the clouds (the whole atmosphere, really) of nearby planets and moons from the display (and the landing screen), giving you a clearer view of the surface. It is turned off automatically when you go down to a planet, and isn't saved when you exit, since it isn't considered an option. The filter has no effect on certain planet types (like thick-atmosphere planets, non-consistant planets covered in dense clouds, and substellar objects), since the drifter's sensors simply can't penetrate their atmosphere to gather meaningful data about the surface.
- The lander shouldn't get stuck anymore when it's supposed to be coming to you. Before, it could to get stuck on terrain which was almost vertical (because it was trying to get to 9000 units higher than the height of the ground at its position, while also trying to move up to 2000 units above the height of the spot it was moving to next - and if the terrain was so steep that the first height (9000 higher than the ground) was below the second height (2000 higher than the ground at the spot where the lander was trying to go this cycle) it would get trapped in equilibrium between them, moving down and then up without effect). The fix involves disabling the downwards corrective measure (which normally triggered if we get too high above the ground) temporarily if we need to move higher to get above nearby land.
- The status-line has been extended to 42 characters (I needed to use it for debugging on the surface when trying to fix the stuck lander, and also it wasn't long enough to hold "TOO MANY SNAPSHOTS" before ), and if a too-long status-line is sent to the status function, it's truncated instead of overwriting memory that shouldn't be overwritten (which is what was happening before!). BTW, the way this had to be implemented was with a separate fcs_status_extended variable. fcs_status itself is still 11 characters long, and it's still written to (in addition to the extended variable), but the extended variable is what's displayed. fcs_status is being kept (and wasn't just extended itself) because it's right in the middle of the old save data.
- The shortcuts.htm in the docs folder has been updated (a little - it's not woefully incorrect anymore). The old one (shortcuts - outdated.html) has been removed (well, it's in the docs in the source now, actually, just in case we want to look at it sometime).
I've determined that the fastest rotation speed that a planet (or moon) can have is 18:360, which is 51 seconds for the sun to rise in the next sector.
The next set of things I want to do (Unless more bugs are found which need fixing):
I want to implement a more realistic way to determine the color of planets from space, and a more realistic way to determine terrain types of individual sectors on felisian planets (Since albedo can be a predictor of landscape composition in the real world). At the very least, I want to add some way of seeing the terrain types from space. If I revise or replace the algorithms for determining terrain types of sectors, terrain generation will change again as a consequence. I also want to make super-hot (lava) planets' colors reflect how they look on the surface.
I also want to look at the feasability of converting NIV to using starmap2 instead of the original starmap format, and restarting handling inboxes/outboxes for NICE (since Alex isn't here still and never seems to do them now) sometime. That might take a while to get sorted out, though, since it'd require creating programs to handle the process of importing inboxes and making outboxes, etc.
By the way, when you've got the cloud filter on, what you're seeing is essentially the albedo (reflectivity) of the surface, and at this time it doesn't fully represent the color of the surface or water, and it doesn't represent the type of terrain (except that extremely low reflectivities on felisian planets are definitely ocean areas). If the cloud filter is off, you see the total albedo resulting from both the atmosphere and the surface.
P.S. The value I use for CentidyamsToMeters is 700,000. If that's correct, one dyam represents approximately 70 million meters. However, BGreman calculated (a long time ago) a value of around 90 million meters, and right now we don't know which one is more accurate. We haven't even looked at how fast the drifter moves in-system, either, but IIRC a long long time ago someone* determined that it was faster than the speed of light. Presumably the vimana drive is used on a weaker setting for in-system travel too, otherwise relativity would kick all our asses.
P.P.S. I don't remember who determined that the in-system drive moves faster than the speed of light, or when they determined it, but it was in the days when Alex actually visited frequently (or did I accidentally activate a rose-colored binocuscope filter?).