. /../Known Noctis IV Bugs, and.../ 1..1617181920..71
absent more than alex
written by Shadowlord on Feb 02, 2005 06:50
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?).
written by Premier on Feb 02, 2005 09:43
I can't run Noctis CE, and I guess this is the best forum to post about it.

Well, if I run Normal Go! or Alternate Go!, a message pops up saying that these programs must be run in DOS mode, and do I want to close all applications. Clicking No drops me back into the OS, and clicking Yes results in the computer rebooting in DOS mode, display a File Not Found error durin bootup, then automatically booting up again back in Windows mode.

The first time I've run Old Go!, the game worked fine until I left the game (didn't try to land or anything, just moved around in the Drifter, then presses Escape. Ever since then, if I run Old Go!, the game starts up with with the keyboard shortcuts screen, but I can no longer make it go away by pressing F1 (or anything else for that matter). There's also some other problem, since the bottom line in the screen displays a temperature of something like 10000000000000000 Kelvins, and to the left of the temperature, there's a line of random non-alphanumeric garbage. The game itself is not locked up as such (the temperature display fluctuates a bit, and I can take screenshots - of the shortcuts screen).

I've read in the troubleshooting.txt that the pif files might cause a problem with older versions of Windows. I didn't have any error message specifically indicating pif problems, but I do have Win98SE, so I guess that might be related to the problem.

So my question is: what can I do to make it work? And also, is there any specific, technical reason for Noctis CE not supporting older Window? And if not, then when can we expect versions of the later releases that actually do?
written by Tommy04 on Feb 02, 2005 13:24
Okay, so it works now. If HacIRC is still supported, this is what I get on a NickServ server:

written by Mr.fop on Feb 02, 2005 13:36
I suggest making a button that cycles viewmodes to replace having a buttload of separate buttons.
doing pushups
written by Megagun on Feb 02, 2005 14:06
Raah.. Damn Nickserv's!

Can you please do a /debug, zip the debugraw and debugchat.txt files up, and then upload em here? I fear it's got to do something with the server being not THAT nice with it's standards..

edit: as a temporary workaround, type this in HacIRC:
"/user YOURUSERNAME meh meh meh meh meh meh :YOURUSERNAME"

after you've done that, do a
"/nick YOURUSERNAME".

Ofcourse replace YOURUSERNAME with your username.
absent more than alex
written by Shadowlord on Feb 02, 2005 15:12
Premier: First, can you stick your current.bin in a zip file and upload it? And you're sure it does this every time you start it successfully?

In order to try to get Normal Go! or Alternate Go! to work, we'll have to experiment: Try this first: Delete all the *.pif files in the modules folder, and then try Normal Go! again and see if it works.

The only reason it doesn't 'support' older windows versions is because I don't have older windows versions to test it on, and I thought it might have problems with the lack of conventional memory (depending on your autoexec.bat and config.sys) on them.

If removing the PIF files is all that's needed, I should probably be able to make normal and alternate go take care of that themselves on old windows versions (I don't know how to check the windows version yet, but it should be simple).
written by Stellanaut on Feb 02, 2005 23:52
It still crashes when I try to return to the SD
absent more than alex
written by Shadowlord on Feb 02, 2005 23:58
Can you upload your current.bin and surface.bin files, stella?
written by Bensel on Feb 03, 2005 00:17
On some planets, (Lighthouse's Morning Haze to be specific), the HUD is impossible to see. Changing the brightness didn't seem to help.

cd/gifs/Bensel/toobright (7 Kb)
absent more than alex
written by Shadowlord on Feb 03, 2005 02:46
Did you try adjusting just the HUD brightness? (just hold -, without holding ctrl)
written by Algebra2 on Feb 03, 2005 03:43
Suggestion: put temperature, atmosphere, and pulse data in the advanced data view so it's visible in screenshots.
written by Stellanaut on Feb 03, 2005 04:02
my situation and related files:

<link cd/zips/stellanaut/bugginess>
absent more than alex
written by Shadowlord on Feb 03, 2005 06:43
I've found a bug today which I want to poll about before fixing it (P.S. it exists in the original noctis as well as NICE):

1. The number of stars you can see depends on your distance from 0;0;0. I've made an example animated GIF where the distance (which is actually sqrt(x*x+z*z)+(fabs(y)*30), if I remember right) passes 400,000,000, at which point the stars become half as common. Notice that half the stars you could see before actually vanish as you pass over the boundary: cd/gifs/Shadowlord/stars (42 Kb) P.S. In that image, DFH stands for distance-from-home, and RF is the 'rarity factor'.

That's because it depends on your position. I can change it so that the distance depends on the distance from that star to the center of the galaxy, but the stars just on the far side of each boundary, which were reachable if you targetted them from the other side of the boundary, will no longer exist.

There are a HUGE number of stars out there, and it's a pretty big distance to the first boundary, let alone the ones further away, but I know several people (including myself) have been out past several of these boundaries. What I want to know is whether anyone has any objections to my fixing this bug. If it were fixed, the stars on the near side (nearer to 0;0;0) of the boundary would be visible even if you were on the far side of the boundary. However, the stars on the far side of the boundary which you could see from the near side would NOT be visible anymore, no matter what - you wouldn't be able to travel to them anymore.

One exception: You could still (for now) use ST to travel to those stars, if you remember the star's name. However, I'm hoping to move NICE to a better starmap format* - either starmap2 or an entirely new format. (I don't know where peek is, but if we went with a new starmap3 format, I would provide documentation of the starmap3 format at the very least, and might possibly even write code to let NM read the format - though we'd need Peek to add the code still )

2. I also figured out the cause of another bug, but you don't need to worry about that, since fixing it has no effect whatsoever, heh! It's primarily a bug in the modules such as ST or PAR which search for a star, and I think Alex knew about it, but I don't think he tracked down the cause of it. Anyways, it only results in the isthere() function coming up with a slightly different star seed/ID - but that ID is only used to compare with the ID recorded in the starmap to see if this is the right star, and Alex built a fudge factor into the comparison. (Noctis itself later calculates the ID correctly when it needs it) I tested 1 million systems near Felysia's sun, and the highest discrepancy between the incorrect ID and the correct one was about 0.000000000029.

* = If we move to a better starmap format, and this vanishing-stars bug is fixed, then if any of those stars which no longer exist were named in the starmap or had comments in the guide, those entries (for the no-longer-existing stars) will probably be removed.
written by Premier on Feb 03, 2005 14:18
SL: Unfortunately, I don't have the current.bin file anymore. However, I reinstalled the program from scratch, and Old Go! works perfectly now, even after exiting and restarting it several times. Since I cannot reproduce the problem, I think we'll just have to assume for now that it was a freak data corruption in current.bin. Should it appear again, I'll be sure to show you the .bin.
absent more than alex
written by Shadowlord on Feb 03, 2005 14:27
I was hoping to find out if it was the PIF files or a corruption in the current.bin. If you only run Old Go! then no PIF files will be created.
reading this thread
no members are reading this thread
. /../Known Noctis IV Bugs, and.../ 1..1617181920..71
45262, 12 queries, 0.148 s.this frame is part of the AnyNowhere network