[CODE][4.2.0] How to determine if a game object is gatherable

[DarkLinux]

I find this to funny. I truly misspoke, What I wanted to say was CopyPast kiddies not script kiddies. I also was not trying to say that only smart people use C++. Even though we all know C# is an inferior language. I'm just trolling lols.

[Cypher]

Just because all the script kiddies only understand AutoIt and C# doesn't mean that intelligent people need to dumb down there code for them. I know it does not look perfect, but its your problem you don't understand it, so keep it to your self lols

C++ is a disgusting language in terms of syntax (I would know, I use it every day), but even C++ looks good compared to the steaming pile of crap that its Objective-C imo.

Note: Before anyone starts crying, I'm only talking about syntax here.

Because the language you're coding in shows how intelligent you are?

Yes, in some cases it does. There are some languages which are simply unsuitable for the type of programming that gets done here. I'm all for using the language you know best, but you also have to consider using the language best suited for the task.

AutoIt is for macroing, not writing bots and hacks. The fact that you can call unmanaged DLLs from it is coincidental, and not a good reason to start trying to put together memory hacking bindings when C# takes all of an afternoon to learn the basics of.

Heck, just look at the description on the frontpage of the AutoIt website (emphasis mine):

AutoIt v3 is a freeware BASIC-like scripting language designed for automating the Windows GUI and general scripting. It uses a combination of simulated keystrokes, mouse movement and window/control manipulation in order to automate tasks in a way not possible or reliable with other languages (e.g. VBScript and SendKeys). AutoIt is also very small, self-contained and will run on all versions of Windows out-of-the-box with no annoying “runtimes” required!

I'm not arguing about unmanaged vs managed, both have their pros and cons, but in this field AutoIt is a 'beginner's language', once you're past the keystroke sending stage you should move on to a more appropriate tool.

I find this to funny. I truly misspoke, What I wanted to say was CopyPast kiddies not script kiddies. I also was not trying to say that only smart people use C++. Even though we all know C# is an inferior language. I'm just trolling lols.

As both MMOwned and GD have shown, there will always be retarded C&Pers, you just have to ban/ignore them and move on.

[suicidity]

C++ is a disgusting language in terms of syntax

I would have to disagree, I think C++ is a sexy language to look at.. well for the most part. It can get ugly easily.

[Cypher]

I would have to disagree, I think C++ is a sexy language to look at.. well for the most part. It can get ugly easily.

Well, it's not so much 'ugly' as it is just overly complicated. It's not really C++'s 'fault' that its so complicated though, most of it stems from retaining C compatibility.

There are also a number of 'gotchas', such as the following:

std::ifstream File("Foo.txt");
std::vector<int> Foos(std::istream_iterator<int>(File), std::istream_iterator<int>());

The code above looks like it should open the file then parse it into a list of integers, but it doesn't. It opens a file, then declares a function named "Foos" which returns a std::vector<int> and takes two objects of type std::istream_iterator as its arguments...

Stupid C's function declaration syntax...

[Serpious]

Well, it's not so much 'ugly' as it is just overly complicated. It's not really C++'s 'fault' that its so complicated though, most of it stems from retaining C compatibility.

I remember when I started learning C++ (which I am still doing, you can always learn more, right?). I was extremely confused about the syntax. While some things made perfect sense by just looking at it some just looked like a piece of ****ed up shit, pardon my language.

[kouteiheika]

C++ is a disgusting language in terms of syntax (I would know, I use it every day), but even C++ looks good compared to the steaming pile of crap that its Objective-C imo.

Note: Before anyone starts crying, I'm only talking about syntax here.

Seconded. My main gripe with C++ is its ugly syntax - that's why I created my own dialect of it. That, plus the new c++0x standard and c++ is a pretty awesome language. A snippet from my GUI toolkit:

#include "pch.h"

#include^2 "gui.cc"
#include^2 "gui/editbox.cc"

class label_t : public editbox_t

    accessible bool shadow_disabled

    public:

        label_t( const std :: string& text = "" ) : editbox_t( text )

            m_accepts_focus     = false
            m_blinking_enabled  = false
            m_editable          = false
            m_decorated         = false
            m_shadow_disabled   = false

            m_horizontal_margin = 0
            m_vertical_margin   = 0


        virtual int min_width()

            return m_pango_width


        virtual int min_height()

            return m_pango_height


        virtual int preferred_width()

            return min_width() + 8


        virtual int preferred_height()

            return min_height() + 8


        virtual int max_width()

            return preferred_width()


        virtual int max_height()

            return preferred_height()


        virtual bool is_shadow_supported()

            return !m_shadow_disabled


        virtual void generate_shadow()

            surface_t surface( width(), height() )

            auto backup = m_color
            auto yiq = ((m_color.r * 299) + (m_color.g * 587) + (m_color.b * 114)) / 1000

            if yiq >= 128
                m_color = 0x000000ff
            else
                m_color = 0xffffffff

            m_surface.swap( surface )
            editbox_t :: on_repaint()
            m_surface.swap( surface )

            m_color = backup
            set_shadow_data( surface.data() )


        virtual void get_shadow_params( unsigned& samples, float& opacity, float& inverse_sample_weight, float& shift_x, float& shift_y, int& width_fixup, int& height_fixup )

            auto yiq = ((m_color.r * 299) + (m_color.g * 587) + (m_color.b * 114)) / 1000
            
            if yiq >= 128
                opacity = 0.5
            else
                opacity = 1

            samples                 = 1
            inverse_sample_weight   = 4
            shift_x                 = 1
            shift_y                 = 1
            width_fixup             = 0
            height_fixup            = 0


        virtual const char * class_name()

            return "label_t"

What I did:

• Get rid of curly braces. Instead, I have python-like indentation scheme that determines scope.
• No ugly and pointless semicolons.
• No parentheses on common keywords. (if, while, switch, for, etc.)
• Automatic generation of accessors/readers/writers.
• Embedded scripting. (You can write a script that generates your code inline in the source instead of doing it externally in your build scripts.)
• No more header files. You write only one file and .cpp + .h are autogenerated from it.
• Embedded sprintf-like behavior for every string. For example, this: warning( "parent == nullptr for #{child->class_name()}" ) will get converted to this: warning( _merge_string( "parent == nullptr for ", child->class_name() ) )
• Multiline strings.
• Right hand keywords. Instead of "if something == true<newline><indentation>return" you can write "return if something == true"; this also works for other keywords.

By the way - considering this is all offtopic shouldn't this whole discussion be moved?

[suicidity]

I'm sorry kouteiheika, but that's just dumb; That looks like some C-Style programming had a kid with a load of retarded scripting languages. I guess as long as it works for you though, it doesn't matter.

@ Cypher, I agree with that point.

[kouteiheika]

I'm sorry kouteiheika, but that's just dumb; That looks like some C-Style programming had a kid with a load of retarded scripting languages. I guess as long as it works for you though, it doesn't matter.

Then I take it you didn't get the chance to program in those "retarted scripting languages" to get to know how much more productive they are than C++/C#? I don't quiet understand why you call this dumb, but well, if you like typing your redundant punctuation, looking at ugly code and dealing with C++'s braindead way of organizing code, it doesn't matter.

Anyway, if you'd have some constructive criticism instead of "this is dumb" I'll be happy to listen.

[suicidity]

Well..

• Curly braces provide much better control-flow over code, and makes things easier maintain/read.
• Semi colons allow you to do multiple small lines of code on one line ( Call it ugly, I don't care ), and also improve readability in my opinion.
• Embedded scripting..? Use lambdas/manual inlining, both convey intent.
• Headers allow for better code control and libraries, They also convey intent of code immensely. This is one reason I like coding in C# over C++.
• sprintf is gross. There are much better options in my opinion ( sprintf_s isn't one ), so hopefully that internal function of yours doesn't actually use sprintf.
• Already have multi-line strings.
• I don't live in Asia, I read and write left to right; "if ( something ) return;" works just fine, Thanks.

[kouteiheika]

Well..

I appreciate the feedback.

Curly braces provide much better control-flow over code, and makes things easier maintain/read.

I don't see how curly braces can make things easier to maintain or read (indentation > braces), but if it's so for you - fair enough. I don't know what you mean by "control-flow" (?), but according to Wikipedia's definition of that word both provide exactly the same control flow over the code.

Semi colons allow you to do multiple small lines of code on one line ( Call it ugly, I don't care ), and also improve readability in my opinion.

You can still use semicolons to chain multiple lines of code into one; you just don't have to put them at the end of every line.

Embedded scripting..? Use lambdas/manual inlining, both convey intent.

You've misunderstood. Perhaps I should show an example:

#include "pch.h"
#include^2 "tga.cc"

#pragma script_begin

    entries = Dir.entries( './art/' )
    entries.delete_if { |entry| entry !~ /\.tga\Z/ }
    throw "No *.tga files found!" if entries.empty?

    entries.each do |file|

        file =~ /\A(.+?)\.tga\Z/
        basename = $1
        c_name = basename.downcase.gsub( /[^a-z0-9_]/, "_" )

        data = File.read( File.join( "art", file ) )
        puts_header "extern const unsigned char g_#{c_name}[];"
        puts_header "extern const unsigned g_#{c_name}_size;"
        puts_header "extern tga_t g_tga_#{c_name};"
        puts_source "const unsigned char g_#{c_name}[] = {"
        puts_source data.bytes.collect { |byte| "#{byte}" }.join( ", " )
        puts_source "};"
        puts_source "const unsigned g_#{c_name}_size = #{data.bytes.to_a.length};"
        puts_source "tga_t g_tga_#{c_name}( g_#{c_name}, g_#{c_name}_size );"

    end

#pragma script_end

What this does is that it iterates over the contents of 'art' directory and converts all *.tga to C arrays and replaces the #pragma block with the generated content. You don't have to use any external program to do this nor you don't have to modify your build scripts. You can autogenerate anything with this, e.g. #defines from an IDA dump or bindings for all symbols from a library opened with dlopen/LoadLibrary. (At least that's what for I've been using this.)

Headers allow for better code control and libraries, They also convey intent of code immensely. This is one reason I like coding in C# over C++.

The point is that I get a header file *exactly* like I would write it by hand. Besides, you can do this if you want: (Though it's unneccessary in 99% of cases.)

(...code...)
header:
    (...this will appear only in the .h...)
(...code...)
source:
    (...this will appear only in the .cpp...)

sprintf is gross. There are much better options in my opinion ( sprintf_s isn't one ), so hopefully that internal function of yours doesn't actually use sprintf.

Agreed. You've misread - I only wrote "sprintf-like". (: I'm using C++0x's variadic templates with std :: stringstream.

Already have multi-line strings.

As far as I know, C++ doesn't have multi-line strings, e.g.:

static const char * s_css = ""
"::-webkit-scrollbar"
"{"
"    width: 12px;"
"    height: 12px;"
"    background-color: #f2f2f1;"
"}"

vs

static const char * s_css = "
::-webkit-scrollbar
{
    width: 12px;
    height: 12px;
    background-color: #f2f2f1;
}"

I don't have to say which one is significantly harder to edit. (And uglier.)

I don't live in Asia, I read and write left to right; "if ( something ) return;" works just fine, Thanks.

Compare how I would write this:

continue if child.priority == 0
continue if child.allocation >= child.max
continue if child.allocation >= child.preferred

with how you would write it:

if (child.priority == 0) continue;
if (child.allocation >= child.max) continue;
if (child.allocation >= child.preferred) continue;

In the first case both continues and ifs are nicely aligned so it's more readable. (The difference is somewhat bigger with more complicated ifs.) Besides, have you noticed that my version actually reads like natural English?

[Tanaris4]

I like nodes? Wait? Is that off topic?

[DrakeFish]

I like nodes? Wait? Is that off topic?

Nodes are so first page.

[suicidity]

I appreciate the feedback.

...

In the first case both continues and ifs are nicely aligned so it's more readable. (The difference is somewhat bigger with more complicated ifs.) Besides, have you noticed that my version actually reads like natural English?

Yeah, I shouldn't have judged so harshly when I first saw it. It's not all terrible, some features seem really nice.
Overall though, I like C++ and the direction it's going; Hopefully it will break further from C as it grows.

@ Your last statement, I can agree that's nicer to read.. but throw some parentheses in there! I mean, COBOL reads like English.. but it's far from my top list of languages right now.

[jjaa]

Yeah, I shouldn't have judged so harshly when I first saw it. It's not all terrible, some features seem really nice.
Overall though, I like C++ and the direction it's going; Hopefully it will break further from C as it grows.

@ Your last statement, I can agree that's nicer to read.. but throw some parentheses in there! I mean, COBOL reads like English.. but it's far from my top list of languages right now.

I think that braces for code cause more problems than they solve. In the end i think the braces are there for the compiler, not the developer. Using indentation for code scope is basically always done now anyway. I mean how often do you see K&R style in C# or even C++, i would say that at least 90% of the code i see these days is Allman style. The braces are just wasted space, the scope of the code is easily readable without the braces in Allman style. If you ever work on a project, if your sane, you use the same indention across the whole project (and in many cases, at a business level). By using the indentation for scope you are standardizing the indentation at a language level rather than a project level. Which means everyone's code should be readable, regardless of where you find it.