Bobs scripting woes

[TheBob]

Uhu, works! Thanks a lot. Maybe somebody should update the documentation on Rand, it's kinda misleading...

[lwho]

Ohh, right the example in the documentation really says Rand:New instead of Rand.New. I'm just changing the code to return nothing (nil) instead of a valid random generator in this case. So, one will get a LUA red screen when trying to use it. While at it, I'll fix the documentation as well.

Edit: Fix in https://github.com/pioneerspacesim/pioneer/pull/2445

[jpab]

Ohh, right the example in the documentation really says Rand:New instead of Rand.New. I'm just changing the code to return nothing (nil) instead of a valid random generator in this case. So, one will get a LUA red screen when trying to use it. While at it, I'll fix the documentation as well.

I was going to recommend generating an error instead of returning nil, but I see that's what you ended up doing anyway, so I just merged it.

John B

[TheBob]

So... I'm in a point where I'll need to put some models in, though for now only placeholders. Still, I don't even know how that works. How do I get a mesh from GMAX into Pioneer? I can't seem to find a tutorial anywhere on that...

[bszlrd]

Can GMAX export dae or obj?
Edit: this might help: http://www.tutorialboneyard.com/Pages/GmaxExporter.aspx

[TheBob]

Thanks, that will help. I just noticed that I have other unexpected problems right now.

I was kind of under the impression that ship labels were visible for quite some distance (no idea why I assumed that, probably Frontier backlash...). As it is, they are only visible on pretty short range. That kind of destroys my concept of using a landed waypoint vessel as a marker, since you can't find the thing.

So now there's the question about how to best solve this. I think some mission types (and of course the discovery stuff I'm working on right now) would need a way to mark a place on a planets surface. I thought that doing that with an invisible vessel was the simplest way to go, although it's somewhat of a hack. But as it stands, that doesn't help much. I know there's a view that lets you see longitude and latitude (although I can't seem to find the key for it anymore), but that is also not quite an official part of the game interface (still, it would be good for testing).

Currently, I don't know what the most practical way would be to implement this function in pioneer, I don't know the architecture enough, so I feel kind of reluctant to make a feature request for "some way to make a waypoint on a planet's surface".

What would the Dev's suggest that makes sense to request?

[lwho]

The key you are looking for is Ctrl-I, is shows several kinds of debug information.

Not sure if it helps much, but the Player class has methods to set the player's navigation and combat target. This works even with ships that are not "in range". So, the player would see direction and distance then. Big drawback: As soon as the player would select another target, he would lose the lock to the mission target.

Maybe a third kind of target (mission target) that is only controllable from LUA might be nice for something like that.

[TheBob]

Not sure if it helps much, but the Player class has methods to set the player's navigation and combat target. This works even with ships that are not "in range". So, the player would see direction and distance then. Big drawback: As soon as the player would select another target, he would lose the lock to the mission target.

I'll have to see what I can with the GUI (I didn't start that yet), but I can see a potential solution here, thanks.

EDIT: Yap, for now quite sufficient. I'll have to see how I solve the whole GUI-side handling (as far as I gather, I can make my own page? Then it should also be possible to put a button there that sets a discovery as a Nav-target. That would suffice for starters. This thing has a long way to go anyways).

Maybe a third kind of target (mission target) that is only controllable from LUA might be nice for something like that.

Yeah, something like that... kinda like it was handled in I-War.

[TheBob]

Okay, here's a few questions about LUA, how it handles and stores datatypes and even something Pioneer related.

Since the project I'm working on is a potential savefile bloater, it is important to me to save the stuff as efficiently as possible. I have the most efficient structure here, but I'm not sure if it's really going to work, and I have even less idea of what LUA will do with it exactly.

First, the structure bases on the assumption that the indices of static bodies in a system is always the same. Is that assumption correct?

And second, I kind of doubt that LUA will just put things into the smallest possible data type. Somehow I just don't expect that kind of efficiency from a scripting language. The other question, of course, is wheather the parser can actually handle anything smaller than an integer. Here's the most efficient structure I came up with:

Code: Select all

discoveries {}
	SystemPath system
	systemDiscoveries {}
		BYTE bodyIndex
		bodyDiscoveries {}
			BYTE discoveryIndex
			BYTE discoveryStatus

It's several arrays of tables within each other, so that there is no duplicate information whatsoever. Also, it seems unrealistic that any system has more than 256 static bodies, so a BYTE should be enough to store the body index. And the other two values are directly controlled by me, and 256 states is plenty to store either of those values.

So, presuming that the Pioneer parser can handle single BYTEs in file IO, how would I force LUA to store these values as BYTEs? and if the parser isn't up to it (which parser is still up to chipping single BYTEs nowadays, after all) how would I force LUA to at least store them as unsigned integers? (come to think of it, I could at least combine discoveryIndex and discoveryStatus into one single integer... plenty of states to go about)

[robn]

First, the structure bases on the assumption that the indices of static bodies in a system is always the same. Is that assumption correct?

You mean the bodyIndex field from the SystemPath object? Yes, SystemPaths don't change - they're a reliable reference to any static body.

And second, I kind of doubt that LUA will just put things into the smallest possible data type. Somehow I just don't expect that kind of efficiency from a scripting language.

Lua will use at least a 32-bit type for integers internally, and might use a 64-bit integer if that's more efficient for the current platform. It will convert integers to double-precision floats (64-bit) and back as necessary. You can't really influence that.

Strings are stored as sequences of bytes, so you could do structure packing inside strings. vstruct is one library that will help you do this. There are a few other libs but they all seem to be written in C, which requires you to recompile Pioneer. You probably don't want to go there.

One caveat here: Pioneer's Lua serialiser (used for savefiles) will treat a 0 byte in a string as end-of-string, so if you start packing structures into strings you might find you get corrupted savefiles. If you find this to be the problem, file a bug report with a test case. Its not on my list to fix/change right now because I'm half way through rewriting the savefile system.

Also, it seems unrealistic that any system has more than 256 static bodies, so a BYTE should be enough to store the body index.

The game uses a 32-bit unsigned integer for body index. Not that I think we'll ever use that much, but there's no such limitation or assumption in core. Take care!

Something to be aware of: the Lua serialiser is space-hungry. Its more interested in saving data that can be reliably reloaded across platforms, rather than saving space. So you might jump through a bunch of hoops to make Lua not use as much memory, only to find you don't get similar gains in the savefile. If you do structure packing you'll get some gains still, but perhaps not as much as you'd think. And its only going to get worse when I finish my savefile rewrite, because then all savefiles will become giant JSON structures.

The other thing to remember is that most of the time you're trading space for time. You're going to be constantly packing and unpacking your data, which takes time. In Pioneer Lua you need to go fast, otherwise you slow down the rest of the game. Meanwhile memory is pretty cheap. I'm not saying don't go to this effort, but make sure its really worth it. You might find that just using plain boring Lua data types makes you go faster and doesn't use that much memory. You've still got a long way to go before you start to catch up with the couple-hundred megabytes of terrain data that Pioneer keeps in memory. If it were me I wouldn't worry about it all, at least not until it shows itself to be a problem.

Good luck :)