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.

Topics - gigafunk

Pages: [1]
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.

Bug reports / Dotnet core version proton
« on: April 28, 2020, 05:51:08 am »

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.

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 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.

Pages: [1]