JayNic

I think maybe the diminishing point of return for gyros, and inertial dampers needs to be greater - that is to say: the diminishing point of return should show up sooner. That would actually mean that super mega ships WOULD be slow, and smaller destroyer type vessels could still be utilized.

That's what I mean - gyros, and inertial dampers were never his desire. He reacted to the loudest feedback. Now it's too damned easy to build battle-cruiser sized fighters

It's a beautiful dream

Thanks Aki! With your tip, I was able to put together a module that is self contained as follows: --[[file: lib/mylib.lua ]] local M = {} --private function local function doThingOnServer() print("I'm on the server") end --public function local function doThing() invokeServerFunction("doThingOnServer") end M.doThing = doThing return M consumed: --[[file: player/myPlayerScript.lua ]] local MyLib = require("mylib") function initialize() MyLib.doThing() end

I disagree. Categorical diversity would still permit players to build things outside any of the specifications. Just certain game play elements would not be available to a ship outside any class restriction, and classes could only do what's in their field of responsibility. Which would work for people some of the time. Or many people most of the time. Or some people much of the time... you see where I'm going For example: I don't really see the point in the NPC freighters - why not just destroyers with cargo blocks? The pro of a classless system is that anyone can build anything they want at any time. The con of a class system being that people might feel railroaded. The con can be negated by permitting classless ship designs, but denying smaller gameplay elements to a ship outside a required class. This not only adds an additional layer of game logic to facilitate more detailed factions, and npc economies: but adds additional player gameplay as well. Win win The con of the classless system is that... well.. everyone does the same thing. My train of thought takes me on this route: Without defined areas of responsibility: there's no reason to diversify. Without diversity: there's no reason to specialize. Without specialization: we're all just grinding to be the biggest and fastest...

Hmm interesting. When I played through, I don't actually feel the need to build massive. In fact: I stayed much smaller than most until I just had tonnes of resources. I agree that NPC ship sizes should be much more varied. As it currently stands: everything is around the same size, and it means everything really just feels the same. As I think through things in my head: I keep coming back to ship classes... It would be an easy way to add a semblance of reasoning in to configuring ships both on the player side, and the NPC side. For example: I really like the idea of running a trade ship, and mastering some cargo routes: but there's really no reason... why wouldn't I just build a giant battle ship with cargo space? Whereas if there were classes, it would add an abstraction layer around the logic of ship design. The class system could be variable in both size, and statistics. So for example, the rules would be based on things like the following: * XX% of the mass must be cargo space (or) * The ship can have no more than XX% cargo space (or) * The ship must have at least XX% mass as cargo space Using these (and obviously more) rules: you could add on additional gameplay logic. So that if you're an "official cargo vessel" that meets those requirements: you would get gameplay benefits to trade. Maybe more stations trade with you, or you get better prices, or you get more relation bonus' Conversly as a cargo vessel: you could not have as many weapons: so there would be a reason to hire escorts etc... Or if you stayed around a series of sectors for too long running trade routes: pirates would catch wind of it and come after you... or something... just spitballing

Hey all, I'm having a bit of a problem - maybe someone can help me out I can't seem to figure out how to get the invokeServerFunction/invokeClientFunction to recognize if I am inside a module --[[file: myFile.lua container module for this and that ]] local M = {} function M.requestFromServer() invokeServerFunction("M.serverFunction") end function M.serverFunction() print("Server function!") end return M the server function is never called... presumably something with scoping? any ideas on how to get around it? Maybe there is a better way to build my modules that will work with the calls? thanks EDIT: I consume the file like so: --[[file: someinterface.lua ]] package.path .... local myUtility = require("myFile.lua") function initialize() myUtility.requestFromServer() end ALSO: Still think it would be great to have a modding help sub-forum...

I love this game. Way too much... And like many people: abused the hell out of the thruster stacking capabilities a couple versions ago... Then... again like many others: got ticked off when my ships all of a sudden didn't work in the new branch. I was dismayed at how slow everything was, how I couldn't fly my massive frigate like a fighter... But then over time, I started to realize how much I actually enjoyed feeling the power behind the vessel. I realized that there had been no space game out there that gave me the true feeling of piloting a capital ship - they're all arcadey! I started to see the merits of it, and while the flying was slow - it was supposed to be slow. If I wanted something nimble, and quick: I would have built something nimble and quick. But I didn't. I was in a 550m destroyer with 16 rail guns. And I liked it! I like the feeling of this power being held in check by the forces of physics. I like getting auto-targeting turrets, and taking on multiple enemies at once with more complex combat than simply pointing my nose at them and holding down left mouse... I like the level of detail that it could bring to the game with a few more ship sizes out there for the AI. The way I see it is that with the originally envisioned model: the complexities of combat and fleet management would promote clever thinking, hiring mercenary escorts, ingenious ship design to cover all angles, multiple "classes" of ships to facilitate different needs. But now... now that the whiners got their way squeaky wheel got the grease: I feel the only way to go in ship design and progression is... bigger... Just build bigger... there's no disadvantage to having one giant ship that can do everything... This leads to an eventual galaxy full of super ships, and that's all... Who can tank the most So here is my hoping - after waiting years for a game like this (since my childhood days of Escape Velocity) that koonschi adds in two simple different game modes: arcade and hardcore. Arcade for the simpler flight mechanics, and hardcore for the true vision that (I think) he wants...

Devious, I'm making sure I'm doing this recording on the client. The server only has to provide the information: because it doesn't look like I can get the goods from a call on the client... which kinda sucks... But the most minimal amount of work is done by the server: the client will store it in memory. I'll test whether or not the memory get's too bogged down - but I'm not anticipating it. Push comes to shove: and people are saying their ram is through the roof: then I'll ONLY load the data at RUNTIME on the client when he opens the browser: and I'll ONLY permit the user to search within a given faction or maybe within a limited radius... Hopefully it doesn't get to that point. It feels good to have actually made a solid step... It's a far cray from me not knowing any lua since I started on this.

Antimodes, I've taken to storing the data as lua tables - these can then be directly parsed back to objects with loadstring. For now: I'm not going to go external DB/api route... I'll keep it simple. I have them pretty-printing now and they store in a trext file in a pre-defined path: - I'm going to have the file written each time the player enters, or leaves a system. That way the data is always up to date. I'm toying with the idea of simply storing all the data in memory during play: and only writing on disconnect... But if there are crashes - it might mean the player loses his play-data... so maybe not...

Yeah Devious: that's the idea! I was thinking of creating a spreadsheet, and I just thought to myself how annoying it would be to have to input/search for data. Then I though I could just output the textual data for easy copy paste IN to a spreadsheet - at which point I decided there wouldn't be THAT much more work to create a full in game searchable db... I think for simplicities sake: I'm going to continue along the line of the pic I posted: Create a text file to store the data in each system the user goes to. The file name contains the galaxy seed (but with non-alphanumeric replaced with underscores, in case I can't create a file with funky symbols) as well as the coordinates I'll store the following info: Station name/type Good name Buy or sell last unit price (of the player) stock max stock That's all! Then I'll monkey with the ui scripting to build a basic paginated list. Hopefully an input text box to allow the user to type in what they want to get. That, or a picklist type deal to select a particular good. That'll be it for now. I'm REALLY not experienced with LUA, and haven't really looked in to the UI scripting api, so that is more than enough for me to bite off. Long term: if this fails horribly: then I move the database to a webservice, store all kinds of stuff with simple little GET params, then integrate a more complicated search feature that actually fires off a request, performs a query on a PHP/MYSQL backend, and returns a parsable table that gets interfaced in to the ui script. That's the ferrari version. Anyways - wish me luck!

Solved it - Thanks to SkeletonKing for helping me out. You need to shut everything down (steamCMD, AvorionServer.exe) duh-doy... Then run the following steamCMD commands: login anonymous force_install_dir c:/your_dir app_update 565060 -beta beta validate NOTE: This will override any server.bat configuration that you've done, so make sure to re-write that before you start it up again. eg my server.bat file is: bin\AvorionServer.exe --galaxy-name JayNic_Dedicated_Galaxy --admin my_steam_64_id --datapath C:\avorionserver\serverData --seed JayNic

Hey guys, I've followed the guide here: http://avorion.gamepedia.com/Setting_up_a_server to get a dedicated server on another machine running, and it works. But I'd like to move it to the beta branch... Is this guide still relevant? Is there a different way without using steamCMD and just copying files from the steamapps game dir? I've done some googling: but it seems much of the information is not relevant, or out of date. I'm a bit confused... Thanks

I'm hoping for the simplest possible solution with extremely easy installation. I hadn't really considered using an actual database because of the over-all complexity of the implementation. Add on to the fact that this game is still early in it's existence: the chances of architectural changes that will result in re-writes of the system would be pretty high... As it stands, I don't think there is a way to save any data directly to a player - that will persist across his play through. I think you can save data to the SERVER but even that (I read somewhere) is currently bugged... Additionally: I'd like to have all this work being done by the client, anyways. And yes, you're correct dwarvenlord1; saving the seed is the unique identifier. I wrote that in already, and was playing with just appending it to the file. If I go to an actual database: I'd want to just put it up on a webservice somewhere. Then build a basic JSON api to grab data. This then involves getting a parser in lua, and converting the results to lua tables... It's probably the most reliable model: because then the player is a pretty slim client... But... then there's always worrying about versioning... Ensuring the client is up to date, or maintaining older versions of the api... blech... This is sounding more and more like my job... (developer/consultant)

I WAS thinking about an external db too... I'm quite experienced with good ol php/mysql. This is the first real project I've ever tried to undertake in LUA - (the only reason I decided to do it was because of the good documentation, and the fact that this game is really well programmed.) Definitely want to share it. Just wanted to get over this hurdle before I move forward - cause it could be a show stopper. So you're saying that you don't think the file parsing/searching would be too bad? Cause here it what I'm thinking if I break it down in to single responsibility modules. Module 1) Data gathering. This is pretty much done. This part gathers all the stations buy/sell data when you enter a sector, including the current price. I can add more things like you say - for example the person who discovered it. etc... Module 2) Data storage. Store all the data as the player plays in a bunch of tables. These tables can be sorted and interfaced with through the scripting api. This is the "database" part - but just a flat table, really. Module 3) Parsing stored data HEre's where I have some black holes in my mind - cause I'm not sure I know enough about lua/the game to answer these questions... If I was to store EVERYTHING the player had discovered in a single text file - where each line is a single good at a single station, then maybe I could just load that entire text file in to memory when the player joins up, store it all in to the tables, and the interface takes over from there. Then when the players LEAVES the game... (or maybe even leaves a sector) I just write the whole thing back to the text file... Seems like it might be overkill... like: my programmer brain tells me that I should really just write a single text file per sector... but my lazy/simple brain tells me I should just do one big write at the end of it all. If I do one big write: then there is the chance that during a crash: the player will lose his data cause he won't kick off the onPlayerDisconnect event which is where I would trigger the write... So I guess... If in your opinion: parsing all those text files when the player opens the "tradabase" window won't cause a nasty cpu hit: then maybe that's the simplest way? Thanks for your thoughts, btw. Greatly appreciated.