Jump to content

Rinart73

Members
  • Posts

    414
  • Joined

  • Last visited

  • Days Won

    4

Rinart73 last won the day on August 19

Rinart73 had the most liked content!

About Rinart73

  • Birthday 06/02/1997

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Rinart73's Achievements

5

Reputation

  1. Currently we can remove all child UI elements with the use of "UIContainer:clear()". It's good, but when building dynamic UI an ability to remove individual elements would be very handy.
  2. TextBox: It would be nice to have "setTextNoCallback" function similar to what we have with CheckBox, ComboBox and other elements. Another great thing would be to have the "cursor" property both writable and readable. Right now if I'm changing TextBox value while user is typing, cursor is always reset to the end, which could be confusing for them. If "cursor" was readable, I could've saved old position, changed the text and then restored the position.
  3. The ability to change faction name would be nice. Even if it's only when it's just being created: function initializeAIFaction(faction) faction.name = "United Federation of Planets" -- other code end While we do have the "Galaxy():createFaction(name, x, y)" function, it doesn't allow us to insert that faction into factionmap and automatically give it a bunch of sectors.
  4. Or to add the color wheel that is already used in the Settings -> UI color
  5. The following Player client callbacks would allow to do some build mode modding: onBuildModeBlockSelected(lastBlock, blockIds) - would fire when player selects block or group of blocks. lastBlock is the block that was just selected. blockIds represents ids of all selected blocks. onBuildModeBlockUnselected(lastBlock, blockIds) - would fire when player unselects block/group. lastBlock is the id of the block that was just unselected. blockIds are all blocks that are still selected after that. Or nil/empty table if none. Examples of that people want to do with it: Color-picker - I actually already have one written already Custom color presets/palettes
  6. The current bonus system is amazing. It's extremely powerful. result = (base * baseMultiplier + multiplyableBias) * multiplier + absoluteBias Hovewer there are still "stats" that don't follow this system: Thrusters - basePitch, baseRoll, baseYaw Entity - damageMultiplier Durability - maxDurabilityFactor I understand that it would require lots of changes but I propose to change the listed stats above into StatsBonuses and to use this system for the future stats, since it allows finer control and for multiple mods to modify the same stat without conflicting each other or breaking stuff. I've seen at least 3 separate people trying to make a yaw/roll/pitch system upgrade. They all run into issues. I personally wanted to use all of the stats above in my mods. But currently damageMultiplier and maxDurabilityFactor are just sometimes directly set by the game which overwrites my changes. And thruster stats are reset on plan update I believe and stacking them is pain.
  7. Make so ScriptUI() "registerInteraction" and "registerWindow" return their optionIndex. This will allow to properly track with what option a player interacts in following functions: onInteract(optionIndex) onShowWindow(optionIndex) onCloseWindow(optionIndex) interactionPossible(playerIndex, optionIndex) This is especially useful when several mods add interactions to the same entity or even modify each other. ---- On the same note it would be good to have "ScriptUI():getInteractions()" which would return a table of scripts with all their registered interactions. Numerical keys are optionIndex-es. { ["data/scripts/entity/merchants/researchstation.lua"] = { [0] = "Research" }, ["data/scripts/entity/merchants/consumer.lua"] = { [0] = "Trade Goods" }, ["data/scripts/entity/somemod.lua"] = { [0] = "Do this", [1] = "Do that" } } ---- Now to the matter of starting interactions via code. Currently it's only possible to start/force Dialog, but not function/window. To fix this I propose adding "interactScript" function, which would start any type of interaction in any script as long as correct script path optionIndex is provided. ScriptUI():interactScript(scriptPath, optionIndex) -- Example: ScriptUI():interactScript("data/scripts/entity/merchants/researchstation.lua", 0)
  8. Add "onClosed" callback to all "Window" objects. Right now when I'm working with nested windows I have to hide native close button and use a fake one in order to track when user closes the window.
  9. I suggest to add an explicit non-async syncronization step that would happen after client downloaded the mods and connected to a server but before any sector/entity/player scripts are created and initialized. Mods would use this step to syncronize their server-side mod configs with connecting clients and then they could use the "setGlobal" function to store them on client. Why do we need it Because there are cases where the standard post-initialize 'client uses invokeServerFunction("sendConfig") -> server uses invokeClientFunction("receiveConfig", config)' method doesn't work, because it's asyncronous and too late (happens after "initialize"). Examples Adjust item/upgrade prices - by the time we syncronize settings Equipment Docks have already initialized items with vanilla prices. Adjust system upgrade stats - by the time we syncronize settings, game has already created tooltips with vanilla values being shown. Override SectorSpecifics - imagine someone created a quest that turns volcanic planet into an earth-like planet as a result. It's an actual visible impact that player could make on a galaxy. But if someone would log in while in that sector they would still see a volcanic planet because the game requested SectorSpecifics before syncronization completed. And in general modifying anything that client Lua or C++ side uses during the "initialize" or before that. As an additional bonus this will slightly decrease traffic and client RAM usage in the heavilly moded games - because some mods would syncronize configs only once (instead of once per every modded entity) and store them in one place. How I see it We could use something like the main.lua, but for both client and server. Server: SomeHelperLibrary = include("myhelperlibrary") function synchronize() local config = SomeHelperLibrary.loadConfig("ModName") -- getting config ready to be sent (perhaps stripping unnecessary info) return config -- THIS will be sent to the client end Client: function synchronize(config) -- we receive config and save it setGlobal("MyMod", config) end then showing updated price ("data/scripts/items/energysuppressor.lua"): local myMod_create = create function create(item, rarity) local item = myMod_create(item, rarity) local config = getGlobal("MyMod") item.price = config.energySuppressorPrice return item end
  10. I suggest posting a bug report via ingame "Report Bug" button
  11. symbiote, Please post your client & server logs
  12. There is no quick way to do this via UI. You could try to make a backup of "C:\Users\YourProfileName\AppData\Roaming\Avorion\mods\modconfig.lua" and switch it depending on what mod set you need
  13. No idea tbh, try to ask in the Discord. You could try to ask server owner for mods list and check your subscriptions - maybe you have installed it already? Also check your client logs for errors.
  14. Yes, they could "steal" some traders. If you disabled buying then yes, traders for them simply won't spawn. If I remember correctly, if you have > 0% extra price, it will make traders more likely (but not guarantee) to sell goods to your factory rather than buy (because you pay extra for those goods). And if you set < 0% price, they're more likely to buy from factory rather than sell, because you're selling goods for a cheaper price.
×
×
  • Create New...