Shrooblord

Ah, sorry. That sounds like you might be running into other issues than a simple patch-to-security-update-compliance-fix (PtSUC?) will solve. You can access the in-game console by pressing the quote key (the one with ' and " on it). This may be displaying errors, which will help you pinpoint where things are going wrong. If that doesn't work, reply here again and I'll see if I can take a look. Good luck, and welcome to the modding team! ;>

I just did a big derp. I forgot part of what made my own modifications work in the first place. Updated that now. Version 1.4 is here to greet you. The "[!]" symbol and all changes mentioned above are now Beta Branch 0.20.2 compliant. This mod replaces /entity/bulletinboard.lua, so will clash with other mods that modify that script. bulletinboard.lua needs to be installed both client- and serverside. MoveUI_ShipNotifierAddOn-v1.4.zip

If it's simply making the mod compliant with the 0.20.2 security update, all that needs to happen is adding callable() function calls to the appropriate functions. Search the scripts included in this mod for the word "invoke". You should get hits that include either invokeClientFunction(), invokeServerFunction(), or both. Then you look inside the brackets for that invoke function. For example, say you find the function call invokeServerFunction("updateTooltip"). The word enclosed in the parentheses is updateTooltip, so we're going to have to find the function called updateTooltip() in that same script. Once you find updateTooltip(), scroll down to where its end statement is. Put the following code after that end: callable(NAMESPACE, "updateTooltip") where NAMESPACE is the script's namespace. In our example, the code shows: function AncientGate.updateTooltip(ready) in which case, the namespace is AncientGate. If the script has no namespace, your job will be a little bit harder, and I suggest you either ask for help again or try and namespace the script yourself. Finally, add the following code at the top of the script, near the other require statements (or just place it near the top of the code if the code has no requires): require ("callable") ----- In summary, your changes will alter the code in the following manner: require ("callable") ... function NAMESPACE.x() invokeServerFunction("y") end function NAMESPACE.y() ... end callable(NAMESPACE, "y") Good luck! There's honestly not a lot you could break performing these updates. If you get it working, do post the fruit of your labours here -- it helps the community a lot!

I've included Bix's changes, my own changes, and made the mod Beta Branch 0.20.2-compliant, so it now uses proper "callable" functionality. I have reverted the colours back to what I like though...... ;D Installation instructions are the same as on the first post of this topic. MoveUI_ShipNotifierAddOn-v1.3.zip

Version 1.2 released! Now includes opt-out functionality for modders. This version update contains opt-out functionality so that modders creating custom Stations can make sure their Station doesn't get any AutoDocks added to it if they don't want AutoDocks on their Station. See the main post for more details. ======= 1.2.1 Fixed a bug where the opt-out functionality would not correctly remove AutoDock functionality. Opt-out functionality should behave as expected now. See updated installation instructions.

Some of the UI is hard-baked into the C++ side of the code, and us modders can't touch it if that's the case. For many "basic" elements such as the Turret Icons, their placement, the healthbars, etc., this is true. So I expect that, no, we cannot remove the grey bar. What *might* be possible is that one could remove the "overheats" modifier from the railgun completely, stripping it from the game. But only if "overheats" is a property added to the railgun in lua script and isn't baked into the behaviour of what defines a weapon as a railgun. But that's also beyond the purview of this mod, I feel.

Considering we just got a massive overhaul to how orders work for AI ships, and that we can now order ships around all over the place with somewhat sophisticated command structures, what is the life expectancy of this mod? The current system doesn't have grouping, and some of its commands do different things than what this mod did, so it's not like this mod's functionality got integrated into vanilla. Does the mod still even work in the current patch and/or Beta Branch, though? Will you be looking to work more on this again, w00zla, or should I mark this mod deprecated?

I think the materials are added into the game engine through the C++ side of the engine, i.e. baked into the .EXE by the time the game arrives on our side. So no, we couldn't change the fundamental way Materials work, nor add new ones, nor add new Blocks for that matter. Sadly, this is how it is for now!

Annotated the comments so it's clear what mod they're from and cleaned up the code in one or two places. v1.1.1 is compatible with Beta Branch 0.20.2. Warning: this mod replaces a vanilla asset. Back up your data before use. To install, drag the data folder inside the .zip enclosed in this message into your main Steam Avorion installation directory. Useful_Cargoshuttles.v.1.1.1.zip

Nice idea for a mod! I'll check it out. Correct. This is now possible on Beta Branch 0.20.2 using the Loop command on a Captained Ship on the Galaxy Map screen.

Version 1.1 released! Now compatible with the 0.20.2 Beta Branch security update. Running smoothly with no problems detected so far. ------ Sorry folks; haven't been on the forums in a while to answer your questions. I will address them now! Indeed. There used to be a problem with ShipScriptLoader -- at least, that was my experience --, but it seems to have been resolved at this time. With a clean installation of the current 0.20.2 Beta Branch (uninstall Avorion > Install Avorion > Patch to Beta 0.20.2), the installation instructions now no longer require you to modify your ShipScriptLoader installation. See the first post in this thread for more information on how to install AutoDock v1.1. I don't think you're running into a conflict. Rather, follow the updated installation instructions as I detailed in my answer to the previous question. I'm sorry to hear that! I will update the installation instructions to make it more clear. See the first post in this thread for details. Oh, indeed. And the bigger the ship, the better this works, I have found. But big and small ships alike, it feels amazingly fun to fly at a docking beacon at 2 km/s and dock no problem. If you've tried bigger ships, you should notice the docking beacon sticks further out from the dock than with smaller ships, making the approach to the beacon (and thus, the station) safe for both. I've tested on the current 0.20.2 Beta Branch and it's working without a hitch. Please tell me if you run into any further problems. Most likely it's the ShipScriptLoader instructions that have now been updated. See the first post (same answer as to the previous two questions regarding failure of installation). ------ If you run into any problems running this on 0.20.2 Beta Branch, please let me know -- I'll try and respond quicker this time.

Thanks, dnightmare! Sorry for the mislabelling! I will bump it up to stable for 0.19. ---- Hi folks! I pulled another one of my disappearing acts on you. Sumi! I'm back for now and currently testing Beta 0.20.2 -- what a bunch of amazing updates Avorion has gotten recently! I'm super excited. The list is being updated again as I test mods' compatibility with the current Beta Branch.

What is load up? As soon as you launch the game, i.e. you can't get to the Main Menu? Or do you mean once you've selected a game to load / create new game and go into the loading screen there? How long did you wait for the loading screen before exiting the program? It can take a short while sometimes.

Do you mean compared to when one player launches 240 fighters (i.e. 120 from two of their ships)? Otherwise, of course 240 fighters in total are going to give more network presence than 120 fighters.

INTERESTING catch, Bix. That signifies that the UI itself is constantly refreshing, perhaps even for all alliance members at the same time if even one of them has the window open. The window is inactive during a drag, you see, so that's why the lag disappears. This should give y'all brainy coders something to look into. ;) (I would but I am otherwise engaged making Player Warp Gates a thing.)

I've never been able to get Trading Posts to work, even in Single Player. For me, it appears they have different goods that they buy from goods that they sell. The result is that AI Traders don't know what to do with them, and so they never push their wares. It's annoying. Factories / Mines - now this intrigues me. When I create a Factory and/or Mine, AI Traders come from all over the joint to come get my goods. A couple of questions: Did you set the settings for the Factory/Mine to "Actively request Traders"? You can find the menu for this in parts of the Factory/Mine's UI when you've boarded it, in the top-right hand part of the screen. In the same menu, you can set buy/sell profit margins. Buying goods at higher rates will increase the likelihood of a Trader coming to sell you "ingredients", while selling goods for a reduced price will encourage Traders to come get the stuff you produced. Are you currently near any (friendly) AI Factions? The closer you are to (friendly) AI Factions, the more likely it is their Traders will spawn in your Sectors. This has been vanilla behaviour for a long time. There's mods to fix that, but you don't want them, I assume.

Awesome, I was already replacing many of my links manually. No need anymore, now!

I saw that, and I freaking love it. Also noticed that the Strategy Mode seems more... responsive? The ships are now performing my commands as expected, where before they might decide on their own volition to just not listen to me, which was frustrating (and made me never use Strategy Mode for its intended purpose - now I do!). Awww but I was using that "feature" to create Turrets with floating heads, à la 1990s classic Sci-Fi turret designs (think Future Cop: L.A.P.D.). :'(

Holy shit, that's a mad life hack! Wtf! Also, nice suggestion, Kamo, to have a Flak escort. Things have gotten so much more interesting ever since the Combat Updates launched...

This should be incredibly easy to mod in. There's already code in-place to check whether a certain ship is a Civilian craft, i.e. ship.isCivil() iirc. The only thing you'd need to do is to modify the target-acquiring functions in the patrol.lua and related scripts to first check whether the "enemy" ship is Civilian, and if it is, not to attack it. To make this behaviour toggleable by the user at run-time will require more effort, as you then also have to build in some UI elements somewhere. But making "don't attack Civilians unless I expressly make you" the default is a cakewalk. Anyone interested in taking on this task? I'm currently still very much engaged turning player Warp Gates into a reality.

Did you base your code off of my code? I did mention I modified the colours to make them more readable, as the deep purples the mod originally used were incredibly hard to read against the dark background of space. You can simply check what the original mod used if you're not happy with the colours.

Yikes, that's 8 minutes of loading time? I'm sorry for you, dude... if I had those kind of loading times, I would have a much rougher time modding the game... I like most of your suggestions. They would definitely add a great deal of value to the game. Even if "the loading screen" seems like such a low-priority feature, it really isn't. You're gonna be seeing that thing at least once every time you play the damn game. In that sense it's as, and perhaps even a lot more, important as the main menu. This, however, is potentially problematic. Server scripts check constantly for the player; if you suddenly "didn't have" a ship, i.e. it was unloaded, you might end up getting put in a Mining Drone, or triggering the "Your ship was destroyed. You have been returned to your Reconstruction Site." behaviour. At least, that's how it is currently. However! There may be a "best of both worlds" approach that's actually incredibly easy to implement, code-wise at least. desc.invincible = true This simple piece of code, when using local desc = EntityDescriptor() in combination with Sector():createEntity(desc), turns Entities into invulnerable objects. For example, Gates are created as Invincible Entities. In fact, you may not even need EntityDescriptor() at all. The entitydbg.lua script shows us that you can simply call Entity().invincible = true to render an Entity Invincible at run-time. So a possible solution/hotfix to what you request could be to instantly onSectorChanged() perform a Player(playerIndex).craft.invincible = true , and wait for the Sector to finish loading. Once it has, simply toggle Invincibility back off before dropping the loading screen. For other players / AI, the player loading into the Sector might be a waste of torpedoes as they're currenly Invincible, but at least this gives you that Loading Screen Protection you crave. Perhaps you could even show some special graphics while Invincible is on in this manner, for example a green shimmer, or indeed, not even render the loading player's ship at all until loading has finished.

Not sure if this is the correct place to request such a thing, but certain read-only attributes would be really nice to have writable. I'm thinking of things like Sector.name. If we could rename our Sectors, we can make our Galaxy feel much more alive, and part of our own creative expression. I'm only asking for a switch from a read-only attribute to a writable format. I could take care of the renaming functionality (including checks to see if you "own" the Sector etc. etc.) by way of a mod. But I can't mod in the write attribute of engine-defined values...! Other read-onlys that would be awesome to have writable: -Alliance.name -Alliance.color1, Alliance.color2, Alliance.color3 -Faction.name -Faction.color1, Faction.color2, Faction.color3 -Player.color1, Player.color2, Player.color3 This request is basically all in name of carving your own identity into the Galaxy as you play Avorion, which in my opinion is one of the key draws that make Avorion so engaging. Let's make that even more engaging.

I like the suggestion, but how does this solve the problem you linked to at the top of your post? If you command the Fighters to go salvage tiny pieces of wreckage, you'll end up with that same behaviour as before, where they get stuck on tiny pieces of wreckage. Also, wreckage despawns over time. No need for cleanup crew on tiny pieces of wreckage; the server will take care of them eventually.

Indeed, I have run into many "decoy" claimable Asteroids. This is not a bug, just the game trolling you. There's also ore-rich Asteroids that use the same model for the Claimables, but at a slightly reduced size. I love those; they're usually somewhere around 80k-120k rich in ores!