Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Exception

Members
  • Posts

    1170
  • Joined

  • Last visited

    Never

Posts posted by Exception

  1. What did you even do to have that bit of code missing…?

    It doesn't just randomly disappear.
    Anyway, add it back into your modGraphics (or similar) module. At the top, you'll see a bunch of similarly named variables. Put it back there.
  2. Hello Eclipse,

    I'm in need of a logo, and all of my current attempts so far have sucked. I'm willing to pay to have somebody make it for me. If you are interested, please show me the following:

    * Examples of previous works.

    I'm in need of:

    * A .PSD (Photoshop [CS5 compatible]) document with the logo in question. Willing to accept .SVG or .AI (Illustrator).
    * The logo to be pretty high resolution (At least 300 DPI, at least 800px by 800px in size).
    * Relatively quick completion (15th October would be ideal)

    I do not need variations, just one large copy broken up into multiple layers (or at least easy to deconstruct if .SVG is the preferred file).

    I'm not looking for anything complex. I will give details to whoever shows interest.
  3. @'leebunee':

    > Hello,
    >
    > I would like to use a nonstandard size of sprites. They are 48x64 in a single frame. Is there a simple way to getting these sprites to display correctly in the current EO variants?
    >
    > **EDIT: I just realised, could I just enlarge the size of the sprite to 64x64 so that they are classified as big sprites?

    Please note the date this topic was last posted in. It would have been better to create your own topic.

    Anyway, EO automaticlaly handles nonstandard sizes, just make sure that your spritesheet is structured correctly and it will do the rest for you.
  4. Now that I have your attention from all caps,

    This has been an issue for a while now. Several members have requested this, and I've yet to see one actually get a response to this now.

    Members cannot post in boards such as Programming, Moderators themselves can't seem to post without requiring approval (if that is ther for a reason, it is redundant; they can just approve themselves), and more.

    Somebody needs to go through each board and just make sure permissions are as they should be. Not later, do it now before it gets sidetracked again!
  5. @'Helladen':

    > Did you release this publicly? I never said privately. I didn't say anyone did it, cause I never seen it done properly.

    I did! About 3/4 years ago I did this with Iron Prelude.

    My apologies, I can't expect you to know that, however why I responded in the first place is covered next.

    @'Helladen':

    > Not saying it is impossible to do or that I am the only one able to do it. People always think I think I am better than the world, delusional individuals.

    And I think that, because _that's the way you come across_. 

    You always present yourself as if everybody around you is wrong and you appear to sneer at those who couldn't do it right, and rather than correct them or offer some steps to improve you'd simply brag about your perfect solution and how bad everything else is. 
    (see: "A lot of people have done it, but they have all sucked. [… no suggestion here other than self plugs ...]")

    @'Helladen':

    > I always respond with programming is one of my worst skills.

    Funny, I don't see that disclaimer anywhere else in this thread. Why is that now relevant all of a sudden if you didn't bring it up before?

    @'Helladen':

    > It is more of a design thing.

    It's more of an implementation thing (As far as I'm concerned, the UI can be made to either re-position itself depending on window size or have multiple implementations for various sizes (as an example, 1 for less than 480px in width, less than 960 in width, etcetc). In the case of multi-platform games, normally a hybrid of the two).

    Reasoning follows.

    @'Helladen':

    > Resizing a form is messy. Most games don't allow this, they also disable the maximize button due to how poorly Windows handles WInAPI.

    I can agree with that it's messy, however it's not impossible to manage (actually, it's quite easy. Provided it's been implemented well, it's just a case of passing in the size to whatever recalculates the lot for you, resizing your buffers, making sure that it's redrawn, context loss is handled, and a few other generic things). 

    It's just a case of wondering if it's worth the effort to allow users to set the size how they want.

    For 3D games (which function generally independently from resolution in that they work with co-ordinate space (usually) from 0 to 1/-1 to 1 and the aspect ratio of the window, and because of that handle resizing with little effort to begin with), it almost never is worth the effort.

    For a 2D game (whether it's managed or not, the co-ordinate space is provided transformed values from the window size, and because of that require a few things to be redefined when resizing), that's more debatable. I think it's worth it.
  6. @'Helladen':

    > [drivel snip]

    Speak for yourself. 

    * I managed it with a resizable window. I rewrote the camera "method" to achieve this. As you say, you see more tiles and the maps center. You also see part of tiles correctly.
    * I (re)wrote the GUI system entirely because the typical CSDE implementation that nigh everybody uses around here makes little sense, is horribly scattered and is unwieldy. It resized nicely and could re-arrange if the window got too small.
    * "Basically, you don't want to allow the player to mess with the window form size, since it can be sized too small, or cause problems where certain tiles aren't completely shown."? What were you doing even to result in this? Why is it a problem if a tile is only partially shown? The edge of the map isn't the current focus. They can come to that when they walk over it!
    * "it is bad for the player to have to resize the form manually to what size they want plus it is harder to do.". Create it well enough, nope, not hard to do at all. While I did give players set resolution options, they could resize it as they wanted too. It's no different to putting in their custom size when recalculating where the set sizes were passed.
    * Overall, this wasn't very hard at all. You rate yourself too highly.
  7. @'GalacticGlum':

    > Wow! Don't need to get your nickers in a twist… Why you mad?

    Re-read the very clear first sentence: don't confuse correction for malice.
    I'm not mad, I just particularly dislike conjecture and am actually, ya know, answering the question correctly.

    If this site is ever going to move on from the dregs of VB6, misinformation simply will not do.
  8. **Please do not try to help if you cannot substantiate it or do not understand what it is that needs explaining yourself.** I say this many times: it is detrimental to who you're trying to help, the sentiment is appreciated, but overall it is unhelpful.

    In Eclipse Origins, many of the UDTs have Data1/Data2/Data3/etc. The reasoning being that it's rather difficult to store "dynamic" properties, for example, an item type that's a sword might need properties that define its damage, parry rate, block rate, etc, but a healing potion does not need such thing (however, that itself may need a property to store how much it recovers).

    Item types vary largely, and it'd be wasteful to declare every property, so the MS4 devs took the liberty of condensing down what wasn't shared. It's simply making the best of a rather crippling limitation (In VB6s case, this limitation is lack of [coherent] inheritance/polymorphism which would make this massively easier).

    (On an unrelated note, this is part of why I dislike many of the attempts to update EO to a more modern language; they retain very bad programming practices that have no place outside of literally making the best of a bad scenario.)
  9. @'Jeppe':

    > […] I've tried following a tutorial but I get the error that Buffs arent a variable […]

    In other words, you didn't follow the tutorial properly. Go back to your source code before adding it, and follow the tutorial again, this time, actually take your time.
  10. It's possible. Don't think anybody's done it (before anybody comments, no, a roof system is nothing like what is being described here. A closer implementation would be sub-maps/regions).

    Given the crappy map structure, it would be quite a bit of work. In the end, it probably won't be worth it (all you gain from it is the ability to see who's below you, I guess?), you're probably just better off using multiple maps to represent elevation.
  11. **I highly doubt there is anybody else who can do this effectively for you on this site.**

    EDIT: just saw your addendum, so this explanation is probably redundant for you, but I'll leave it up for somebody else to read.

    >! tldr: read the damn valve source multiplayer wiki, it's much more informative than this conjecture.
    >! **Preface**: there are WAYYYYYYY better implementations than the following (see: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking) but having never tried to do any more than the below (which was entirely based on guesswork and conjecture), I couldn't begin to explain any other method anywhere near as concisely as this.
    >! I have no interest in opening up VB6 again, but I did attempt pixel movement in the past (like, 2/3 years ago. The result was alright, the implementation was less than desirable), and I almost got it to a decent working state (I never finished combat for it). While this has its flaws and probably isn't an ideal implementation, it did work generally, so I can try provide some theory on what I did (ie. _not correct to reiterate again_) to get you started:
    >! * When the player presses a direction, you send the server a flag to indicate they have started moving. The server then sends to the other clients that the player has started moving, alongside with their position.
    * When the clients receive this indication, they process movement and move positions themselves.
    * When the player releases the button for the direction, they send the server a flag to indicate they have stopped moving. The server sends this to other clients, and does a check to see whether the distance moved is correct (as you know the speed and the time taken, it's a simple case of calculated distance = speed * time. If their distance is out of your calculated distance [with a specified tolerance], it indicates that it should be corrected). If not, the server will fix that. The position is sent to the other clients. Because the speed is set, it's possible for the server to extrapolate where they will be at any time during the movement.
    >! For collision, I let the client do the work (simple bounding boxes for each blocked tile. Could probably have done it better) and have the server verify if that was the case.
    >! For battling, in theory, it's another case of letting the client do the work (I gave attacks a radius and an arc range, so players could swing in front and it would check within that sector if the opponent was there) and, again, having the server verify and actually execute the attack. I only got as far as having the client do that, no server checks were made, so battling was…interesting.
    >! Flaws:
    >! * By letting the client do most of the work, it's relatively easy to circumvent the checks and, well, do anything, for somebody who knows what they are doing.
    * In an ideal networking environment, this works fine. In a typical networking environment (I did test this), it works fairly well with some occasional jumping from the server fixing the position. In a bad networking environment (ie. lag), in theory, this pretty much falls apart.
    * lol i wrote this in one go when i had no clue what i was doing and didn't do anything to improve it, it likely sucks.
    >! Again, to reiterate: there are WAYYYYYYY better implementations than this (see: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking) but having never tried to do any more than the above which was entirely based on guesswork and conjecture, I couldn't begin to explain any other method anywhere near as concisely as this.

    In the event you can't find anybody, you're better off working with the constraints you have. You _could_ reduce the tile size to, say, 16x16 and work from there.
  12. @'leminhde':

    > I coundn't find file exe to run it !!!

    **Short version**
    I'm going to put it quite plainly: you shouldn't be running this.

    **Long(er) version**
    In order to compile and run this, you need Visual Studio (I'm not entirely sure which version as I've not used this. Looking at the solution file tells me Visual Studio 14 _). This project is currently not available for general production use, only C# programmers really can use this and really do much with it at the moment; in other words, anybody who does not have a full idea on what they're doing with this shouldn't be using this. _
  13. I'm no pixel artist, but I suppose it always helps to know the basics for sprite touch-ups/modifying, etc.

    ![](http://p1cs.me/AW.png)
    At 1x:
    ![](http://p1cs.me/AX.png)

    The one above is assuming that you're working to 32x32, the one to the right is assuming that you're 16x16.

    For either case: make use of your canvas. Your hearts could be bigger, especially if they have such a relatively large shadow and especially considering that they're to be used (I assume?) to display key information.

    As stated by Mohenjo Daro; note that curves progress from 1 hop to 2 hops to 3, back to 2 and 1 again.

    Maybe slightly change the palette. I left it as is, but if I were to modify it further, I would make the outline lighter and the shadows darker.
  14. You've definitely improved, it's hard to imagine you were once one of the more irritating members of the site!

    I do have two qualms though:
    1) On your site, your most recent (and generally better) work is at the bottom while the older (and generally worse) stuff is at the top. Please invert the order!
    2) Waaaaay too much work is displayed and there are a few that __really__ shouldn't be there (massively inferior quality to the rest like the Epoch Explorer or the PMD Online logo). You should pick only the very best of your work and display that if you're showing your portfolio to prospective clients.

    I may be in need of a GUI and a logo shortly if what I try making continues to suck, so just throwing that out there. :>
×
×
  • Create New...