Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 29 May 2000
Offline Last Active Today, 12:38 PM

Posts I've Made

In Topic: LibGDX texture error when camera translating

13 February 2015 - 06:43 AM

there is nothing wrong with the code you pasted.  your problem must lie elsewhere.


and you need to be significantly more detailed in the problem besides "the map becomes lighter or something"....

or something could mean literally anything in the world.  rendering the map makes your computer explode falls into the category of "or something".


give more detailed description of problem (best with screenshots) and more code.

In Topic: Microsoft Visual Studio Language To Choose

13 November 2014 - 07:20 AM

.net is going cross platform (at least to linux) as microsoft just announced.

For game programming with C# I would look at the .net version of SFML (my personal choice) or monogame

In Topic: prevention of loops in transfer of [consumable] between game entities

12 November 2014 - 03:03 PM

always transfers energy to the storage node with less energy, the quantity of which is no greater than half the difference in energy between them (i.e averaging). Note that this is a hybrid push/pull approach, since the energy can move either way depending on how much each storage node has as the time the contract is executed.





I think that is it and can solve my problem for the storage to storage transfer.  Just check if the other has less energy as me then transfer.  So it they are in a series like

Producer -> Storage1 -> Storage2 -> User

it will still get energy passed down to the user (but will take a tick or so) because one storage 1 has 1 energy, it will pass it to storage 2 that has 0.  Storage 2 will pass it to user since there is no less than energy required it just gives it to the user.  Next tick producer gives 1 energy to storage 1 and it again passes it to storage 2 since it has 0 (remember it gave up its energy to the user last tick)...and so on.  Energy will start to build up in the storage once there is more flowing through the system than the user can utilize meaning a transfer DOESNT happen from S2 to S1 and that cause a transfer to not happen from S1 to S2...and effectively S1 and S2 will fill up at about the same rate.


At least this works in my head sitting here at work.  Going to try it out when I get home.



In Topic: prevention of loops in transfer of [consumable] between game entities

12 November 2014 - 01:44 PM

@Zipster  The thing I dont like about your method of summing up all the energy and averaging out is that during each tick (could be the update rate of the game or once per second doesn't really matter) an energy transfer can only go 1 hop (I am in networking so I kind of see similarities in this to routers).  For example energy cant go straight form my producer above to the user because it is 2 hops away.  It would have to go form the producer to the storage in one tick, and then from the storage to the user in the next tick.  Or if the storage already had some spare energy one tick would be from the storage to the user of its stored energy, and then from the producer to the storage.


@Buckeye  That might actually be a little more than I asked for.


I think I am going to do up a prototype of a variant of my Method 1.  I will try it with allowing 1 energy unit to be sent out each link from a producer each tick (right now max is 3 connections to producers so it wont be infinite), and not just only allow 1 energy unit total and have to choose a connection.  Then with the storage it will allow the same thing (so will act as a producer) as long as it has enough energy in reserves.  If not enough energy in reserves to fullfill all links then will prefer users over storage.  And then users will just detect each tick if they have energy now and blow something up with it.


Yes this will cause a small storage to storage loop, but the net effect on them is 0 so nothing is lost/gained and still means the producers are the only ones who create new energy.  I think this will allow energy to get to the users without having to fully fill up a storage first.  However I think it will turn out that a storage will have to completely fill until the next storage down the line can begin filling and wont simultaneously.  Well....if it is structured like my above pic they could fill simultaneously, but if they were connected just only in series then it would produce a problem of waiting until a storage completely fills before passing it down the line to a next storage.


Maybe I can throw in a detect that if I am a storage and just receive energy from another storage, don't send it back when its that ones turn to tick.

In Topic: C# higher level network library

09 July 2014 - 06:47 PM