• Welcome to AtomicTorch Studio Forums.
 
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - gigafunk

#1
What is the timeline on this? I cant wait to play again
#2
Farmers and merchants should have to trade their goods to fighter types to get prag. Fighter types should collect prag and use it to buy gear and food.  That only works with a good economy, so for small pops you need to find a fighter type person that does not like farming to trade with.


Otherwise,  I collected 250 prag from the desert in about 3 hours with a hover and MAYBE 10% fuel and a laser pistol and 10 charges.  If your on a PVE server, there is not much stopping you from that(maybe other people getting them, I was on an empty pvp server) , if your pvp, your going to need a group or at least a partner to survive the month anyhow. 250 prag is at 15-16 solar panels. 7 days worth of ALOT of power and no wood chopping. 14 days of a little less power.

Prag is supposed to be hard.
#3
Well, they would be trapped in their claim. They have to be in there for it to kick on. So they cant be gathering and growing and you can be, and eventually they will run out of power. And while they are busy making batteries, you can make guns and bullets and bombs and be ready when they come out.   


Maybe crops/lith pumps/oil freeze while the shields on?  Thats drastic, but there are so many way to balance this idea.

And, if the bloodthirsty have to wait around or try a couple times to catch a smaller group on, go cry. As it is, the KOS bloodthirsty king-of-the-hill style players are too shortsighted to understand a game that lets you kill everyone the first week is not fun after the first week....

With this change  the servers wont go dead after 2 weeks and maybe we can even have them run longer than a month. and break the king-of-the-hill gameplay cycle that is fun enough, but holding this game back from being being super amazing.

If this is a thing, how long? 3 months? 6? I am going to finish up next server wipe, and want to be back as soon as some version of this is being tested, with 2-3 friends.


#4
Bug reports / Re: Dotnet core version proton
May 14, 2020, 07:08:23 PM
Course it couldn't be that easy as to set padding! Thanks for the info,

The new release of wine with the mono update  was rolled into a new version of the custom proton made by "Glorious Eggroll" I spoke of earlier. 

I tried it, and the same thing. In the proton log I can see where it loads cryofalls included shared binary, but I can also see it loading one as part or the "Proton" set of changes to wine. I tried vanilla wine of this version and it didnt work either,  I am going to dig a little bit and see if its easy to turn off the Proton loading of their own dotnet stuff. This is on top of the wine mono environment.

Next i will delve into trying to turn off that from loading into the proton "prefix".

Anyhow, Ill keep updates here for the curious

I ended up firing up my windows partition to play this, but im still going to probably fruitlessly hack away at it.
#5
Sounds interesting. I like the idea of a revenge window, but if you get online raided your probably unable to exact revenge that day lol. When the raiding players are at your base, their base will be unshielded, so if your large enough you could send a breach force while you have some blocker/defenders, and that is as proposed. So revenge windows should be looked at but after we see how the game starts to take shape after this.

This may enable longer inter-wipe periods, and allow trade to develop and discourage the "quit until next wipe" mentality that hurts this great game.

It may require alot of balancing, but you have a lot of balance points to tweak.

I also propose , down the pipe, but keep in mind when designing this shield if you like it ,some sort of "capital" shield that enables safe trade within an area, nullifys weapons, but allows randos to move in and out for commerce. Maybe this costs prag to maintain, maybe they have to maintain a close base that is always vulnerable, like the start wars death star shield.

Your right a change like this alone could allow the emergent patterns to start to open up more.
#6
I propose a server in which is PVP only allowed around prag sources, if you are holding raw prag, in an event circle , or in a radius around oil seeps and lith nodes. Maybe in the desert as a whole, maybe not, maybe in the ocean and new areas , maybe not.  Depends on whats needed.

Maybe this requires no oil or lith in any biome without the temporary nodes. 


I dont know if this should be another post, but a
Also a new raid mechanic in which you build a "tribute" shrine outside someones claim. Now they have a time (24 hours?) to start paying a tribute, maybe 1 prag per claim spot per day. If the timers runs out, the tribute builder/demander/receiver can raid the claim. While under tribute, maybe tribute clan can enter and look through chests (not interact) to make sure they are not stockpiling weapons to overthrow them. Maybe the tribute payer gets a credit of a day if the tribute reciever wishes to exercise this power.

But claims on nodes do not have this protection.


I believe something like this would create a dynamic top end pvp game of people collecting tribute payers and maintaining nodes and would allow for and required longer server wipes times and would create a place for solo mostly pve type players and large groups and break the "king of the hill" zero-sum game that is currently played on pvp servers.



Note on holding prag pvp. maybe you glow, if someone shoots them, they glow for a time. sure, non prag carriers could run around blocking with their bodies, but that cost durability and is fair meta-game. This could be solved with a pvp radius around prag carriers. This is delicate as may create grieving opportunities. If the "no run and shoot" or "run minus shoot ability" mechanic are put in place , that may help. But I would rather people meta game non pve body block that create potential grief.

Note on events. Yeah you may get trapped in one. RUN. Its dangerous out there what can I say. This could be solved with a 25-30 second prefall event in the area so you can scram. if it falls around your base....stay home.

Note on tribute shrines. Maybe a base technology, the throne maybe. and maybe the tributes must radiate out from the throne. maybe it grows as you collect tributes, maybe you HAVE to collect tribute from each successive claim in the way to grow. then a mechanic need introduced when a solo claims land already under the kings control. maybe an initial wood tribute that gives them a week or two to start paying the regular tribute.
#7
Bug reports / Dotnet core version proton
April 28, 2020, 05:51:08 AM
Hello,

Carrying this over from the steam forum.

I have been poking around with this, far out of my league and found a log file entry that I did not see shared before, though I could be wrong.

https://pastebin.com/deKSR00h

line 29 is the interesting one

System.Security.Cryptography.CryptographicException: Padding is invalid and cannot be removed


I know you had it narrowed down to that so I figured this might help, although it seems its out of your control and in wine, and maybe its a good clue for the wine crew to see and maybe its at the heart of a larger .net bug.   Ill go post it on whatever wine has for a bug tracker, after I track it down.  Proton has one but its for games that are already certified or whatever verbage they use.

Thanks for all your effort on this, its really cool and exciting.  I just made the switch from windows 10 and every game I have tried works in proton.  Ill update this post with any news from the wine world.


Ok first I see that the 5.7 version of wine that was release on april 18th I think, updated mono from 4.9.7 (i think) to 5.0.0.  So Sooner or later Glorious Egroll will probably release proton compiled against this newer version, so I am going to hold off bug reporting with wine until after that and I test it.

After tons of google, and not knowing much, and based on everything you typed

Maybe that the system.security call SHOULD be made against the standalone binary, but mono has that method and wine is calling it instead, and the mono method is assumes the wrong padding size vs the MS one? 
I read you MAY be able to workaround it by explicitly stating the padding size for both decryption and encryption, but that a workaround for a "bug" in an unsupported system , and that might be total crap

I will test this as soon as i can get ahold of a test proton compiled against wine 5.7 and update this and then proceed to wine bug reporting.