Sorry for the dely in replying. I wrote a longish reply this morning, left it, came back, and closed the browser forgetting I hadn't sent it.
There's no trial atm as a trial version requires a separate product code built into the compiler. A new code can only be distributed when an update is distributed. Rich says they may be able to do a trial mid-january (along with an update I suppose).
Quote: "DavidT, forgot the 5.8 compatibility, i upgraded to 5.9, but i have a 5.8 Backup hehe..."
Cool, let me know how it goes on.
Right, X trade. I'll read through and comment...
Quote: "thank you.
i think i already understood most of that.
i jsut wasn't sure if it was reliable sending two messages in a row, but i think that would work."
You can use the messgae system however you want. Queue up action to take, pure notification of events, etc. They're stored in a queue so there's reliability to worry about
Quote: "e.g.
send message "set health"
send message "1"
send message "15"
should work i assume "
Each message can have a bit of data associated with it. So from Lua you could do
SendMessageI("SetHealth",15) (send int)
SendMessageF - float
SendMessageS - string
personally I'd steer away from DBPro storing the play data, and have it all stored in Lua, and get DBPro to query the lua array with the data when it needs it. But that's just me - there's no right or wrong way of going about it.
Quote: "i'm not really sure what i want it for, jsut think it might be useful.
my main project is a Space Sim... and i think it would be useful for controling my ship's AI, and as you said (and i said), i would probably script most of the game and write the 3d engine in DB, which would be great as im doing a complete re-write right now.
it may also be useful for my database program (like ms access, but CLI based)"
Def. useful for a database program. Insanely useful in fact. You can even do sorts etc. on data. Might want to have a look at what "lua tables" can do on google.
Quote: "one more thing:
is it possible to have a continuous, looping script in LUA?
kind of like a paralell process?"
No. It's not truly multithreaded. When you call Lua the dbpro app pauses while the lua executes. This isn't as restrictive as it sounds...
I like to think of the relationship between dbpro / lua as one of events and triggers. To give an example:
- You want to add a new type of enemy to the game
- You write a script detailing how an enemy reacts to certain situations:
function Gunship_Attack()
some code
end
function Gunship_Flee()
some more code
end
these functions define how the type of ship behaves. Then in your game you might want to add an ew ship to the sim, a Gunship.
- Each loop your dbpro app looks at what's happening, and if a ship attacks then the dbpro looks up what type of ship it is and it calls the appropriate Lua function.
- The lua functions then may send messages back to the dbpro app if anything like explosions etc. need to take place.
As you can see Lua is literally loadable logic! This sort of flexibility means people can write their own scripts - their own types of ships - then add them to the game themselves. A moddable game
Quote: "e.g. i initiate a LUA script that has various information and processes vital to say, debuging my application, and it passes information back to the DB app whilst it is running (so that DB doesn't wait for the LUA script to finish executing.
or maybe a line-by-line approach? (similar use to the db sync command in the way that it only updates the screen when you tell it to, maybe we could have control over when LUA reads the next line of a system?"
Sorta answered above. Best to let DBPro drive the actual game, and use Lua for the finer bits that can easily change. Kinda like HTML defines a page layout, but CSS tidies up.
Quote: "and there was something else....
oh yes, can LUA functions in a different file be called from another LUA script? (like #include files) and global variables that are passed over throughought the execution?"
Yes.
Quote: "umm, e.g....
a value of a ship's hull plating rating, which changes throught the game, but is stored constantly throughout the application, so that it is changed when needed but stored other times? (this is kinda related to the constant-execution stuff)"
Variables declared outside of a function are globals and available to everybody. Same with functions - available everywhere. Unless specific, variables from inside a function are not global and reside only within that function.
Phew. Hope it helps.
