Jump to content

w00zla

Members
  • Posts

    79
  • Joined

  • Last visited

Everything posted by w00zla

  1. thanks for your feedback, but unfortunatelly, i cannot reproduce your issue! since i got some questions: what Avorion version are you using (mine is beta 0.11. r7857 atm)? have you other mods installed? can you reproduce the problem and send me maybe correspondig client-log file (its located in %APPDATA%\Roaming\Avorion\)? and maybe its also relevant which rarity the trading upgrade is (mine was exotic)?
  2. just use terminate() instead ... it sets the script to invalid and removes it automagically on the next ocassion!
  3. I think it might be not a good idea, since there are two versions of the game (stable, beta) and maybe there are just some (config) quirks so different mods donkt work for one but the others! but i like the other categories :)
  4. you cannot exchange properties/variables of attached scripts, but can use Entity():invokeFunction() to call functions in other attached scripts and get its return values, so you could create a function to invoke which returns your required values from the script!
  5. sry, was the wrong link: https://github.com/w00zla/avorion-showdist/blob/master/scripts/player/cmd/showdistjump.lua and for the rest aka LUA coding techniques: LUA has no (built-in) concept of OOP and therefore overriding of classes/functions is not possible (there arent even classes in the OOP sense!). Avorion/LUA works by attaching scripts to different game world objects (=entities), which makes those scripts run in the context of the entity (i.e. player scripts are active while player is online, ship scripts are active while ship-entity is not destroyed etc.). You MUST define the secure() and restore() functions (and lots of others depending on their actual intention) in a script attached to an entity for them to work properly (look here how scripts are attached).
  6. There are several options: you can either save values for a specific script instance via this functions (looky here http://avorion.gamepedia.com/Entity_scripts): - secure() - restore() HowTo: in secure() just return some variables and define exactly those for your return() function as parameters (have a look at the code of the showdist mod for an example) or you could set and get values via the "property bag" of Server(), Sector(), Player(), Entity(): - setValue(key, value) - getValue(key)
  7. Einfärben geht bei Chatnachrichten leider nicht! Und nehme bitte eine andere Thread Überschrift, die Leute wissen so garnicht was du genau fragen willst...
  8. So einfach ist das leider nicht, man braucht leider mehr als nur eine Mod: [*]Mod welche den Status der Player und des Servers eine eine Datei ausgibt (solange bis RPC Unterstützung für das Game kommt) [*]Programm welches aus dem Status eine Bilddatei generiert [*]Die Bilddatei muss dann regelmäßig auf einen Webserver oder Image-Hoster kopiert werden damit man das Bild in Foren etc. einbinden kann Ich hoffe das sowas wie GameTracker sowas bald für Avorion anbietet!
  9. thats a pretty interesting and fun idea! i think i will have a look at it... currently following comes to my mind when thinking about the features: - UI for creating and seeing your and all other bounties, and cancelling yours - some sort of escrow system with handling of bounties even when player should be offline - lots of notifications, maybe a permanent HUD display when a bounty is on you - bounties on ships would be possible one thing to clear in before would be how to handle which player gets the bounty if multiple players attack one target... other ideas would be: - special target marker on HUD or notifcations if any player with bounty is in your sector? - overview of sectors in the UI where players with bounty are in - special sectors where players with bounty are invulnerable?
  10. can confirm that, some labels are showing, some not! without ScrollFrame: with ScrollFrame: most labels are gone as you can see!
  11. Pretty nice idea and solution, and I especially like the mod's name :D
  12. good news everyone :D updated the OP and released version 0.6-alpha of the mod! Changes: introduced search modes and related config (by default, the mod now searches only in sectors discovered by the player :D see "HOW TO - Search modes" section in op) mod now tries to auto-detect its configuration for a galaxy (this may fail so you would have to configure manually with /findstationconfig) mod now hosted on GitHub, so unregistered users can download it too, and because of source control, and because why not ;) Please give feedback if auto-detect of config does not work for you (on windows, PowerShell and WMI need to be available)!
  13. Yeah, thats also true, and in Mojangs case really not the "interface" you wished for as a modder... hmm, i really get itchy developer fingers when reading and thinking about a fully-fledged standalone mod-loader for Avorion, but I really would be interested in when koonschi plans to release the Steam Workshop support (a platform Mojang never had for MC modding)! since he also plans to finish the game completely by end of the year (means out of early access), I doubt any bigger mods integration project will pay off .... whats your opinion guys??
  14. I think that may all come with Steam Workshop support for the game?! Here is the question when the support will be released and if its worth the time developing such an fully-fledged loader??!!
  15. since the galaxy/sector files are saved on the server, the server-side scripts need all to be installed, sry about that! Could you elaborate on "only have little performance cost"? Will this mod definitely have at least a minor impact on performance? Is it easily noticeable? Or only barely noticeable? Also: Would the performance hit be even more noticeable on a server that regularly has 10 to 24 players at any given time? This was at least considered on the multiplayer server where I play. However, even after upgrading the server, there are lag issues. And the concern is that - because this is server-side - this mod might make existing lag/performance issues worse. (The thinking is that there is not enough "headroom", performance wise, for something like this.) well, the mod/scripts takes performance only while searching, and the impact is not noticeable on my machine anymore due to the new checking routine. BUT if you've got a busy server thats already running out of spare performance, I would not recommend installing this mod without adjusting the performance settings (see "HOW TO: Performance tweaking" and "HOW TO: Advanced server configuration" sections in OP!). If you set concurrent searches and loaded sectors per frame to 1, I think this runs smoothly even on busy servers without affecting performance noticeably. But you would have to try, as there is defenitely some performance cost due to the scripts reading lots of sector files each search! Hmm, thats really strange, especially because the error seems to reference the "findstationui" command, while you were using the "findstationconfig" one?! Could you please send me your client- and server logs? They are stored in folder "%APPDATA%\Roaming\Avorion".
  16. That sounds really good :) I will give the loader a try and test as soon as this is implemented completely, as this is what I need for my next mod idea!
  17. there is an Avorion Discord out there: https://discord.gg/kSGTDUn I think its run by Aki (forum mod here) and its kinda half-offical ;) it even has a "modding" channel, but there is always no one online when I am ...
  18. you can also use the /run command to add and remove player/entity scripts while ingame! everytime you add a script, it will be reloaded from disk and executed, so you can even edit the files while the game is running =) /run Player():addScript("player/myscript.lua") /run Player():removeScript("player/myscript.lua") /run Entity():addScript("entity/myscript.lua") /run Entity():removeScript("entity/myscript.lua")
  19. From my side, no need to credit for the function, just happy another modder finds it useful ;D Your progress and changes sound good so far, and I would really like to take a grasp on it! did you forget to attach/link your new version or didnt you release it yet?
  20. this is under investigation at the moment 8) the info about discovered, and not created sectors, is stored in the player.dat files, which are binary and their structure is pretty unknown (I didnt find any usable info at least). If I can reverse engineer the file structure and parse its data in an reasonable amount of time/performance, this feature may become available with the next update. But i cannot promise and maybe this will only be available with the release of proper API access to sector/galaxymap data!
  21. ty much, now I understand :) I think its viable to say its kind of a template for entities then...
  22. Dont take my comment negatively, i like your general approach and think your code is already a really good starting point :) I dont have much LUA experience for myself (has been several years since last LUA script before Avorion) and was also struggling with the filesystem/io capabilities of LUA! But luckily LoSboccacc came up with a good solution for scanning directories for files, and i made working function out of it for my findstation mod (works on win and linux): require("stringutility") function scandir(directory, pattern) local i, t, popen = 0, {}, io.popen local BinaryFormat = string.sub(package.cpath,-3) local cmd = "" if not string.ends(directory, "/") then directory = directory .. "/" end local path = directory if pattern then path = path .. pattern end if BinaryFormat == "dll" then path = string.gsub(path, "/", "\\") cmd = 'dir "'..path..'" /b /a-d' else path = string.gsub(path, "\\", "/") cmd = "ls " .. path end local pfile = popen(cmd) for filename in pfile:lines() do i = i + 1 if string.starts(filename, directory) then t[i] = string.sub(filename, string.len(directory) + 1) else t[i] = filename end end pfile:close() return t end this code gives you a table of all found files, with optional search pattern. use it like scandir("<Avorion>/data/mods/", "*.lua") to get all scripts in a dir 8) for the possibilities of a script loader in general (this is just to my knowledge at the moment, please post if you have more info): the only real hook to get custom scripts working without modifying any vanilla files is to create commands = create script files in the /data/scripts/coommands directory ... but we cant influence that in any way and command scripts will always have to go there and be on-demand by the user, so nothing of interest for the loader. I also see only a few possibilities of hooks into scripting by modifying few basic vanilla scripts like "server.lua": - events/callbacks of Server() - events/callbacks of Sector() - events/callbacks of Player() then, of course, the direct attachment of scripts to the Player() entity. If something like a basic entity-script loader is integrated, we could also have the "Entity():addScriptOnce()" mechanism provided directly to mods by the loader, and then have also: - events/callbacks of Entity() All other modifications of stuff, like i.e. trade goods and production recipes, spawns, loot, like you said, require the direct modification of the vanilla scripts, and this is not manageable by a loader without overwriting each "addScript()" line in every vanilla script :o but the loader could of course modify "vanilla scripts of high interest and use" and provide some kind of replacement mechanism and/or simple API for i.e. adding new upgrades or goods, until workshop support comes its way ;)
  23. Player functions and variables are available in Documentation/Player[Client].html and Documentation/Player[server].html. Yet you found some Functions I didn't know existed. I'm interested in such functions for the Entity-object :) also interesting is that the EntityDescriptor (/Avorion/Documentation/EntityDescriptor.html) is documented with seperate functions, dont really know why ... whats the actual difference between Entity and EntityDescriptor then? Anybody knows?
  24. i have the same opinion like rater193. a general modloader would be great, but your approach requires too much tinkering by the end-user. an approach with scanning special mod folders for scripts and including them automagically would be much more handy and less error-prone in my opinion! what do you guys think?
×
×
  • Create New...