. /../Known Noctis IV Bugs, and.../ 1..3031323334..71
absent more than alex
written by Shadowlord on Apr 28, 2005 22:57
Actually that's already in the list of things I want to add. It's just that it would take a lot of RAM (Well, not a LOT, but we're pretty close to the limit now), and fiddling with palettes, etc.
written by Stellanaut on Apr 28, 2005 23:55
Couldn't you use the same map that's in the SD, only have it available on surfaces?
absent more than alex
written by Shadowlord on Apr 29, 2005 00:29
There're two ways to do it: Either 3d, floating in the air or attached to the lander, or 2d, just a flat display. If it's 3d, we could use the same code. However, the colors would be wrong, or we'd have to change the palette colors when you're looking at the screen. Either way that would look really weird. So 3d isn't really an option.

If we do it 2D, we couldn't just have it as a minimap for the same reason. It'd have to be on its own screen. If we do that, we can change the palette colors when we go to that screen and change them back afterwards. By screen, I mean something like when you press F1 and nothing else is visible except the list of keys and so forth.

The problem is the RAM that we'd need for these things:
1. The code to change the palette colors and then change them back
2. The code to draw the map in 2D, and switching to its screen and back (though the switching code would be tiny).
3. The additional code for handling how we show non-felisian planets on the map.
4. Plus we'd need some space to back up the palette entries which we're changing, or we can just regenerate the palette (and everything else) like we do when we have periodic updates. That at least won't require any more code.

All in all, it'd be best to do this for the windows version, where there's no pesky 640 KB RAM limit.
written by Stellanaut on May 01, 2005 19:28
If I try to land on the white spots on quartz planets, it crashes.
written by Micmac on May 01, 2005 22:38
Hi Everyone

I am having difficulty with parsis coordinates in NICE. Everytime I enter the three parsis numbers under the 'Set Target to Parsis' option, the screen says it is locating the system. Nothing happens. Then, when I start the vimana drive, the ship takes me to no where. How am I supposed to locate the system (or planet) closest to those coordinates?

Recently I have been looking at a 'crop squares' posting under the discoveries section of the forum. I entered the parsis numbers, and got no where. Is it possible to locate the system that displayed the parsis coordinates in the pictures?

Any help would be appreciated.


written by Stellanaut on May 01, 2005 22:40
sounds like you made a typo and got yourself in +nan ly universe.
absent more than alex
written by Shadowlord on May 03, 2005 18:21
Micmac: What do you mean by "takes me to no where" - do the stars vanish? Does the ship fly to those coordinates? Or does the ship just not move?

If the ship is flying to the coordinates, but just not reaching a system, then the system's main star is probably somewhat far from the planet at which the screenshot was taken, and your stardrifter isn't automatically locking onto the star as a result. Look for the target 'box' and see if there's a star near it, and if so, try to target it normally.

Alternately, you may have mistyped the coordinates. That happens to me sometimes too.
absent more than alex
written by Shadowlord on May 03, 2005 18:29
Changes in R9:
  • The x/y/z/core menu options no longer also toggle other options in a different menu (A break statement was missing at the end of that case statement.) Also, the nonfunctional 'new terrain algorithms' menu option was removed, and multiplayer has been disabled for now and its menu option removed until we decide to take another whack at it. (This saves several kilobytes of RAM)
  • You can't land on a planet which has drifted far away from you now. Before, if you left drive tracking mode off, and had flown to a planet, you could wander off and come back later and the planet would be out of sight, but you could still land on it without needing to get close to it again.
  • The temperature will no longer be absurdly high when you start NIV with no current.bin. It'll be slightly above 0 K, like it ought to be. The temperature was showing up super-high because of the initial values of nearstar_x, y, and z. Presumably those coordinates were so far away that things were overflowing.
  • A generic work buffer is used for all critter models now, instead of one for each model. This means we can fit more models into the space that's currently available without requiring additional RAM (Since Alex allocated a dozen KB or so more RAM for it than it needed before).
  • Several new critters have been added. The new models are in NCC files in the DATA folder, named Critter1.NCC, etc, so they don't give away what they are by their name. Some are rare, some are common, some are in the middle... Most have habitats they prefer. There may be several subspecies for some (or all) of the new species. Some may not have new model files, being based on existing model files.
  • Split the F1 page into separate in-space and surface pages. When you press F1 you see whichever one is appropriate to where you are. This needed to be done because there simply wasn't any room left. Added Q/A/Z (the lander commands) and the left/right/down/up arrow keys (for sliding, and toggling mouselook).
  • Felisian planets aren't all as regular as they were in R8. There are again planets of predominantly one terrain, and ones with specific mixes of terrain, etc. The 'average' will be 'regular', but there are others. Really extreme ones should be rare.
  • When on a planet, the left and right arrow keys now make you slide in that direction. Tap them to change your sliding-speed a little, or hold them down to rapidly change it. If you hold down the down arrow, it'll slow down your sliding and eventually stop it.
  • Mouselook can be toggled from the "More Options" submenu of the "Extended" menu. In addition to be toggleable on planet surfaces by tapping the up arrow key. If mouselook is on, moving the mouse away from you makes you look up, and moving it towards you makes you look down. This is the opposite of what happens when you hold the right mouse button with mouselook off. The reason it's the opposite is to bring it in to line with most FPSes.
  • Also, a new optional in-system vimana drive is in now. The way it works is that you can use 'start vimana' while you're flying towards a target with the in-system drive. If the target is more than 20 dyams away, the vimana drive will kick on until you're within 20 dyams of the thing, then it shuts back off and the in-system drive starts warming up again.
  • Fixed the "neck is too weak when you're jumping/using the jetpack" bug. Now, you should be able to jump WITHOUT the automatic "look down" effect...
  • Added Raw Screenshot. Use this by either hitting "delete" or "b" (whether in space or on the surface of a planet). This actually takes a screenshot WITHOUT the parsis coordinations, and the often irritating planet/star name tags..
  • Enlarged the forests. They are now WAY higher, and should generally look better now. Note that this is quite planet-specific: on some planets, forests may look ugly (like at Vericalya), but on some others, they might look superb (Felysia, for example).. Also note, that the probability of having a "giant" tree in forests is higher now.. Almost every forest should have a "bigger than normal" tree in it now.. This is actually a side-effect of my modifications to the size of the trees, but you don't have to know that, do you?
  • Added a hail effect. Hail should occur when it's cold and it should be raining... Hail doesn't really look that uber nice, though.. But meh.. At least it looks different from rain...
  • When you lose power, the walls will depolarize now (Since it takes power to polarize them). Also, if invisible walls are on, they become visible again.
  • You can no longer use h, s, r, v, or L keys while selecting a remote or local target.
  • Troubleshooting.txt has been updated. It includes information about possible reasons that GOES modules won't work.
  • There are optional 3d hopper brackets now. The option is in the Extended->Visual Options menu.
  • The Normal and Alternate Go programs now show a warning if you're using 95/98/ME, unless you've made a PIF file for the program. If I get a PIF for 95/98/ME, I can make Go set it up for you automatically.
  • The message you get if you don't have enough free conventional memory is better now, and tells you to look at troubleshooting.txt. It also pauses and waits for you to press a key before exiting.
  • If an attempt to run a GOES module fails, NICE tries to find out why and will try to tell you. So for example, hopefully if you don't have enough RAM it should say so now.
  • Perry reported a freeze/crash bug when landing on a specific planet or changing sectors. It's fixed now. It turned out that the code for making craters on 'creased' planets got stuck in an infinite loop if the albedo of the sector (its reflectivity, or how bright it looks from orbit) was very high. This planet had high albedo in general, so the problem was common there. The albedo was so high that it was trying to make a negative number of craters, and it was set up to continue making craters until the amount left to make was 0. Since the amount to make was negative initially, it never reached 0 and just kept decreasing forever. (Actually it WOULD reach 0 if you left it alone long enough, because of integer overflow and the size of the 'number of craters' variable - That means the number would get so low that eventually it would wrap around and become positive.)
  • The bobbing on the water effect you get when you're on liquid surfaces is reduced now. Now, you shouldn't need a puke-bag anymore... AND you'll be able to gently float on, let's say, Suricrasian seas!
  • Starmap3!
    • You can feed ST, PAR, WHERE, etc, the name of *any* named system or planet (or moon or companion star) anywhere in the galaxy.
    • If you give ST the name of a planet/moon in another system, it will tell you what system it is in.
    • ST, PAR, WHERE, etc, find their targets instantly.
    • Although the GOES modules have been updated to use starmap3, you can still use the old modules. Just add OLD to the end of the module's name, e.g. STOLD, PAROLD, etc.
  • The terrain (visible from space) of different planets was often similar, due to the planet seed having only a tiny effect on the terrain. I gave the seed a greater effect (it affects every tile now), and added another thing to make them differ more (but not much more).
  • There was a buffer overflow in background() - that draws the skies on planets. It's fixed, but might be slower than the previous version. This doesn't fix what causes the overflow, it just prevents background() from writing outside the buffer. (I don't really understand how it's supposed to work, so all I could do was prevent it from writing outside the buffer. Fixing it properly isn't really possible right now)
  • Fixed some more buffer overflows in the following functions: smoothterrain, felisian_srf_darkline, lssmooth.
  • A lot of the keys you can press on the surface will show a message now when they're pressed.
  • Degrassifying with the 'g' key (requested by McWgogs).
  • The GOES modules which take a 'X..Y' parameter now take 'X..' to mean 'X' and all entries after it, and just 'X' by itself means only entry X. Previously it meant X and all entries after it.
  • McWgogs sent me a current.bin + surface.bin which wouldn't work, and it turned out that the local target in current.bin was *nothing*, which was why NICE wasn't loading. However, the current.bin was also incomplete, but it doesn't make sense for it to have crashed where it stopped. Maybe the output was buffered, and it crashed before writing the buffered stuff. Hmm. Anyways, if the local target lock is lost before the cupola separates, or if it is set to nothing (-1) when you try to start NICE, then it will leave you on the drifter. Additionally, if it is ever somehow set to -1 while you're on a planet surface it will immediately put you back in the drifter and tell you something went wrong.
  • Current.bin is now saved just before you land on a planet. It was possible for it to crash after saving surface.bin, never saving current.bin (since when you hit ESC while on a planet it saves current.bin after surface.bin). That could cause problems.
  • Fixed a problem which could cause you to get sent back down to the surface immediately after arriving back on the drifter.
  • The y-axis for mouselook can be inverted now. Just press the mouselook key or option until it says it's inverted (It can be: Mouselook off, or mouselook on, or y axis inverted (mouselook is of course still on)).
  • I think I've fixed the 'endless lightning' bug. I think it was being triggered when the weather cleared up after there had been several lightning flashes already.
absent more than alex
written by Shadowlord on May 03, 2005 18:31
Those of you who wanted a WASD scheme, let me know what you think about the arrow-key sliding feature.

Was anyone using the arrow keys for pointing the camera?

Be sure to read the 'nicer9critter.txt' file that comes with R9. No, it doesn't have spoilers in it.

You can get R9 here:
written by Stellanaut on May 04, 2005 00:32

An odometer, to keep log of how reliable felisian engineering is

Giving a look at the temperature of the environment before you land (if you want to locate a certain type of lava, per say)

Being able to name/catagorize hoppers (those of different colors etc.)

Changing the sky as you ascend out of the atmosphere, darker and darker until you can see space, maybe even change to the space engine temporarily (if atm prs. <0.001, allow for an ascend to orbit, if close to planet, allow for descent to surface), although it would be very low range, only good for getting a quick glimpse of your surrounding regions and possible destinations

Speaking of possible destinations, maybe give a screen that has a series of 25 letters indicating the surrounding land types, maybe for a felysian planet something like this:


X-current sector

It could be a precursur to a map

Of course, it's just a suggestion (maybe a dream )

Edit: oh, and also, keeping the altitude between sectors would be nice (except if you're landed or would-be-sunk-in-the-terrain of course)
└> last changed by Stellanaut on May 04, 2005 at 01:58
written by Cryoburner on May 04, 2005 04:04
I tried NoctisCE R9 tonight, and it was quite nice. However, the game froze while I was exploring a desert sector of a Felisian world. I had recently turned on the critter brakets to locate a new little creature I had been following a few minutes before, if that's of any use. Neither Windows or Noctis would take a screenshot after the freeze, so I took one using my digital camera. : ) [Screenshot] I could still alt+tab in and out of Noctis, but the simulation itself was frozen in place.
written by Raptorjedi on May 04, 2005 04:08
I have had that a lot since I started playing the new version. I don't think we figured out what caused it, I would have it happen when super running then jumping between areas, normal jumping, walking, super running. Turning around suddenly and going right back into an area I had just left did it to me once too.
written by Ysereh on May 04, 2005 05:55
I also experienced the same freeze on two seperate occasions, both while flying around with the jetpack.

( To be more specific, I think I was decending when it froze )
written by Cryoburner on May 04, 2005 10:20
I had a second freeze while exploring a dense forest on the same planet in the next sector that I tried. I had no special view modes or anything active at the time, and was just running through the woods at speed level nine when it froze. I had probably been wandering through the woods, snapping a few photographs, for around 5 minutes or so. I pressed no buttons to trigger it, and was simply steering with the mouse (In traditional Noctis control style). Also, I didn't notice any animals in the sector, but they could have been hidden from view, since the forest was rather thick.
absent more than alex
written by Shadowlord on May 04, 2005 17:38
I was hoping that was fixed, since McW didn't seem to be having it happen to him anymore, and neither was I.

Right now I have no idea what's causing the freezes, and so far nobody's found any repeatable way to cause them.

Can anyone confirm if the freezes happen on non-felisian planets? If so, we'll know they're definitely not caused by critters.

Edit: I'm getting them now on felisian worlds, they just seem to be somewhat rare.

1. It doesn't seem to be due to the weather/sun updating (I made a debug message appear a quarter second before updating, the freezing wasn't happening while the message was visible).
2. Doesn't seem to be due to the hopper bracketing (it still happens with that off).
3. Sometimes it crashes, sometimes it freezes.
4. Doesn't seem to care whether you have the F2 thing open or not.
└> last changed by Shadowlord on May 04, 2005 at 20:41
reading this thread
no members are reading this thread
. /../Known Noctis IV Bugs, and.../ 1..3031323334..71
46816, 14 queries, 0.203 s.this frame is part of the AnyNowhere network