Fianlly finished the texturing in my Tresari Shipyard after putting it off for months.....and months!
Well, I am kinda new to POI building (what I am working on will be my first ever batch) so we shall see what happens. Started working on a weapons factory the other day. Basic frame is done. Doing all of the detailing now.... which is the part that I am still getting the hang of. Mine don't tend to come out quite as pretty as some of you.
Stretching the limits, looking for new ideas, testing stuff... Playing with the "Sectors" settings. I want to understand everything so I check every parameter, and sometimes it gives funny results. Here, what happens when we don't include the "SpaceWarpTarget" around a star, and we have a size 10-12 star model : Stuck inside the star, but cute. Here : the 2 planets on right/ left of screen can never be reached : When pointing at them, we see they are actually at 0.1 AU, although they are right next to the player : I can "warp" to that planet, but when I get there it's just too far to ever be reached... We can also completely "ghost" through the planet (with a ship), and the "fog" color will be the one defined in the atmosphere parameters of the playfield.yaml. Interesting. .
I have been working on this one on and off for a few days. I am not very fond of the actual default "blob" galaxy : it's hard to "map", hard to place factions and plot routes in a scenario to avoid players from being able to jump all over the place. So I made ... a spiral galaxy ! Not very large, not too many stars ( to my taste ) and average distances are quite small, so it might require adjusting warp drives but I think it's a minor problem. Stars are faint because my starter system is located at 300 LY over the galaxy center to be able to see both arms : In the galaxy map view, a bit better (blue circle is my starter sector): So there are lots of "empty places" between the arms spins where we can put isolated/ individual systems. All factions have been distributed along the 2 arms to avoid having them placed in the middle of nowhere, but with this type of galaxy it can be easy to place factions in positions to follow a certain order. If warp drives can't make it across the void between the galactic arms denser areas, then players can be forced to follow the arms or wait for "bridge" systems to cross the void... Here is a "high contrast" view to help see the distribution of stars : Unfortunately we don't have much control on nebulas, and it's hard to try to contain them in specific regions so if I allow too many they will just spawn all over the place. .
I thought for a moment the writing on the tyre said 'FELON' Tire company Eleon... regression is objective, resistance is futile.
Today I was goofing around and decided to go in a slightly different direction. In the escort series I have always had a hangar, starting with a side hanger and then progressing to fly-through hangers. But today I thought, how often do I use those hangars? What would it look like if I cut out the hangar and attached the cockpit directly to the engineering section? So, todays project. I think it came out nicely and would serve well as a starter CV (after a bit more downgrading). The original (with a side hanger) is on the top, the modification is on the bottom.
Yes : it is one of my test planets, where I precisely place stamps and stuff. I need precise measurements to see where the "fake tire" touches/ dips in the ground, because I can adjust the wheel/ axle models but I can't adjust the hover effect's height from ground in a lower-than-1-block precision. Here's a shot where I can see the precise height above ground. Left side is the green ground repulsor, but as a "custom block", and right side is the "original". I can only conclude that the original's distance to ground has been "hardcoded" because its exact copy switches to the regular hover engines height : With this I know exactly how to design the wheel block in Blender... There is a big structure on this playfield, with a slope, to test the hover vessel reactions. It's quite jarring to hit a slope, see the HV rub its nose and slowly work its way up while still completely horizontal despites the slope, then cut the power and watch the HV take like 30 seconds to get to the same angle as the ramp below it. This is utterly, completely ridiculous. Today I solved another part of the problem : now the wheels start turning/ follow the speed of the vessel when it moves/ stops. Far from perfect but, hey, I can only use workarounds... If I had spent all this time on a genuine "wheel vehicle" in Unity, with scripts and custom models/ prefabs and physics, I would have probably a few working examples by now. Which makes me think that if Eleon does not want to make wheels (despites being part of a survey following player requests) it's just because they are lazy. Yup. It's when I looked at @Wanev 's post (#23788 up here) that I got an urge to try to make trucks and stuff because hangars look so cool when they have a real usage. SVs can be "glued" anywhere on a CV, HV look like spaceships but share almost all the same looks/ blocks, but a truck has to be in a hangar. So when I saw that he tried to make wheels, I knew how real wheels would look cool on these models, even if just for "cosmetics"... .
Ok. Adjusted some models, made new imports/ fixes in Unity, exported bundles, started the game... stuck in loading screen. ALT-TAB out of the game screen, Unity's window is completely black, with a very slow progress bar showing "receiving application message". I killed everything, re-booted my laptop. This time I only start Steam (no browser mode) and Empyrion : again stuck in the main loading screen. ALT-TAB out of the game and kill the internet connection. Get back in game, and it finally resumes loading. Once in my scenario, I open the console : Cute. Did I ever say this game has very bad performance problems ? Not that I have a problem with Unity's so-called "customer's experience enhancement politics" or whatever they call this lame excuse at sniffing on gamers machines while they try to run a Unity app, but... If Empyrion did not have tons of messages on its forums and Steam reviews saying how bad the game plays and how even a top rig struggles running it, I wouldn't see a problem with having any amount of events and other data trying to make its way to cloud storage while I play. But if the result is that it randomly crashes the game... WTF ? Unity : "We dig into your game and data while you play to see how we can improve your experience". Ok. But doing so inherently takes away some juice that this game desperatly needs... It also means that "playing offline" is never really "offline". ^^ I am not impressed. .
Given how other Unity games have successfully implemented wheels (like a certain block-building multiplayer sci-fi title, starting with "Robo" and ending with "craft"), I think I agree with you. It's almost dystopian, how every program nowadays needs constant connection to spy on you. It would be, if it wasn't borderline-hilarious, like, our spying process is so ineffective, that it crashes the medium it is meant to operate from. lol.
Besides the 'Spying' on players usage and abusage of most on-line only programs (I truly detest the buzzword 'apps') even in their single player/off-line modes, the thing that bothers me most is how certain fractions of the playerbase seeks out ways to 'cheat' online necessitating patches and rewrites of buffs and nerfs that adversely affect those without the understanding and abilities of these semi professional ultra competitive on-line rouges, and it's ruining games for the sake of it. Perhaps some see me as just a grumpy individual that's not particularly good at gaming... maybe you're right, but it seems that gone are the days of purchasing a complete product that would work and work well providing enjoyable sessions without having to be butchered by updates and patches, yes I know that some games needed patch disks sellotaped to the cover of various magazines but that aside, those days are gone and many times over players are invited to invest in pre-alpha games with promises of a bright future... until these rouge players blaze Easter Eggs across the interweb and test things to destruction over and over forcing patches of patches and complete rethinks of features and envisaged content... As for the wheels... yeah, I'm all for those even though it's not in the roadmap, even if Eleon were to only deliver a wheel in the parts bin we could have a plethora of scenarios utilising them.
While trying to find a solution to HV keeping its nose up when hitting a bump, I found out that by reducing atmosphere density on my planet to 0.001 makes the HV go sideways while I'm not even touching anything : that is the effect of "wind speed" which is set to 1 in the playfield.yaml... So a minimal wind at 0.001 atmosphere density is waayyy stronger than stronger wind at normal density. Makes perfect sense. I just can't believe that whoever made this can't fix it. Only reason I can think of for this is that the person who made this is not working at Eleon anymore, and nobody in there now understands a milligram on the topic. HV defies gravity when turned off. Near-zero air pressure wind has hurricane force... arf...
Unity is quite a b*tch... Tried installing the latest version, made a cool 3rd person controller and small test level, and then as it was nagging me each time I was starting the Unity Hub I finally yielded to the "new Hub update available - restart and install " death trap... The Hub v3.0 interface did not show me any of my projects, and just asked me to log in. I logged in, it opened my profile page on the Unity website, but still the same "please log in" screen in the Unity Hub, and no access to my projects. Started the editor directly without the HUB, then tried to access the store but "You need the Hub to access the store". Googled for a solution, found that I could use a version prior to 19.4 to access the store from the editor. Installed an older version, tried to connect : "You need the Hub..." I tried opening my last project in the old editor, it gave me a few warnings but opened it anyway. I tried fixing some broken scripts, and when I hit "rebuild" Unity opened like 25 versions of the Editor, and did the same with the Hub. Had to reboot. Launched the latest version of the Editor, tried to load my project : corrupted. F*ck Unity. Uninstalled everything, then reinstalled just the BlockModelsandHeadProps project version to see if my Empyrion prefabs were ok. No problem. Enough of Unity for now. Last night I spent 4 hours making a base game in Godot. Clicked on the bad icon (add script) and it just erased my code in the "main" and broke all links... F*ck Godot too... .
Honestly, I think the "best of them" simply avoid working with garbage... ^^ When I started my "learning" journey in "coding" I asked myself many questions : what do I want to do? What tools are there to achieve this? What do the "pros" think about these tools? And what is a "pro" to start with? This led me to deeper questions : what is a programming language, its components, its "mechanic" ? This lead me to also look at hardware related to "run the code" as far back as the first transistors, the first "logical circuits" and old "furniture" that made computers when this all started (heck, I even did some "assembly" tutorials).What's an address? A pointer? What is "casting"? And very often, the crucial "base" topics are just superficially addressed in "high level programming" so the newcomers can spit out some programs quickly else they will give up. They will then produce lots of redundant functions without even knowing it, because these are all hidden behind the language's "keywords" that are only, in reality, abstractions of the underlying C/C++ code below. Thus, some guy will learn cool Python/Mono/Lua-derived shortcuts, which will render code unreadable for someone not familiar with it, and in the end it achieves nothing more than the original version. It still requires an additional line of code in the compiler to translate that "new stuff" into the original, before processing it into machine language. Learning is easy, when the teaching is well done. It's all very simple, and what makes this complex is the fact that some people iterated through the "easy basics" in millions of ways, then made "new languages" each with a complete jargon/ syntax, with new strange rules and formats (indentation = big joke = sell more mouse because mousewheel abuse...). This abstraction tends to produce bloated code where threads get lost in unnecessary intricate routes and hierarchy to perform simple tasks. It sure looks "easier" for beginners, but when trying to make more complex applications where performance is crucial, that "ease of use" quickly vanishes, as well as the "performance"... There's a reason why big operating systems (and ... game engines!!) are all based on C/C++ although it's quite old : it allows far more control on what the code structure looks like, and how it will operate. Longer to write, but that's the only "con" I see up to now. .
Today I decided to continue my experiment of removing the side hangar from some of my smaller builds while keeping the rest of the functionality. I think it turned out well but I am going to continue tweaking them. The originals are on the left, the revisions are on the right.
