Jump to content

Recommended Posts

i'm using your great tool, really good one.
i private messaged you, hope you read it :)

Share this post


Link to post
Share on other sites

A new video: "TypeSqf Features Part 3 - The Power Of CPacks".

 

Content:

  • What is a CPack?
  • How to download and install a CPack.
  • Create a complete MP mission with tasks, enemies, civilians and random traffic in less than 2 minutes.

 

 

  • Like 5

Share this post


Link to post
Share on other sites

It's totally amazing that's its possible to make a mission that easy.

Cpack is awesome for new (all) mission makers...

  • Like 1

Share this post


Link to post
Share on other sites

I really like this c-pack feature, but i don't understand if it's possible to create a c-pack containing a dialog/display or some remoteExec commands. In both you need to define classes in description.ext 

and when you upload a c-pack it's only possible to define one row in one of the init.sqf files and not description.ext


Am i right, and is this some kind of security feature?

 

//Josef

Share this post


Link to post
Share on other sites

Yes, that is the current status.

 

Until I've found a better solution for injecting stuff into description.ext I would recommend to include the description.ext (as simple as possible) in the CPack. If the user does not have a description.ext already it will just be fine, and otherwise user will get a conflict note when installing the CPack. In the latter case user will rename its description.ext and install, and then merge the files afterwards.

 

Another solution would be to explain what needs to be done in the online CPack documentation, but as a user I would personally prefer the first solution because it is easier for me to see what should be done.

  • Like 1

Share this post


Link to post
Share on other sites

New version:

 

Version 0.57

-Added menu item "Videos" with links to tutorial videos.

-Analyzer improvements.

-SQX: Analyzer improvements.

  • Like 2

Share this post


Link to post
Share on other sites

I'm very much looking forward to using this on my current project.  I'm relying on macros to do what you've done with a dedicated preprocessor and it would be wonderful to be able to move beyond notation-heavy macros.  I noticed two things in my first quick test that I got errors on:

 

if (not isServer) then

 

The parser seems not to realize that 'not' is the equivalent of '!'.

 

-----

 

Also, I use a macro which is obtained by including from a .h file.  It is a way to trace function calls, so it looks like this when used:

 

MACRO(method) =

{

};

 

TypeSqf doesn't like it at all, flagging a syntax error on MACRO(method) and stating that MACRO cannot be used as a target for assignment.

 

-----

 

More significantly, I'm wondering about instance references.  Pointers.  ARMA arrays are passed by reference locally, so there are no problems treating them like objects.  But if an instance is sitting on the server and a reference needs to go to a client (equivalent of netId et al), there's the question of how to do that.  Have you tackled this or do you plan on tackling it?  Or is this something that developers will have to do on their own?

 

Like ARMA, I do the obvious, which is to create a lookup table of instances.  Each instance includes its table index, so I can do instance-to-id and id-to-instance conversions.  (I also have the instance's type index in each instance)

 

So my instances look like

 

[type-index, instance-index, property, property, property...]

 

The reason for having a netId equivalent is that I may roundtrip to the client to perform some user interface action, and then go back to the server again.  During that round trip, I want to hang onto a reference to the key object involved.  I send the [type-index, instance-index] part of the key object back and forth.

 

The next step after that is to include the owner of the instance in that reference so scripts can call methods and manipulate property values of non-local instances.  I haven't done that yet, but it's certainly waiting in the wings.

 

-----

 

Lastly, what do you do about circular references between instances?  If parent and child instances reference each other, then you end up with a "recursive array" in ARMA parlance.  I have a reference property type that uses those instance references from above to be able to break that recursion.  If you've found a better way, I'd love to hear about it (such as knowing that we can tell ARMA to stop objecting to "recursive arrays" if they aren't going to be sent over the network.

 

My apologies if you've answered these things elsewhere.  I scanned this post and didn't see anything about more advanced topics.

Share this post


Link to post
Share on other sites

Hi JB47394

 

Thanks for notifying med about the "not" and the macro issue. I always use exclamation, but it should be an easy fix, and I personally do not like macros, so I know that macros are not very developed in TypeSqf. There are only some very basic support.

 

Regarding pointers passed between clients I have no plan to tackle that. To call a non-local method you will need to either publicVariable or remoteExec something, and I see some problems in implementing support for that. The former requires BattlEye configs (to allow for publicVariable) and the latter will require edits in description.ext. And it would be a lot of work, so I leave that up to the users. In my opinion very few objects need to be synchronized between clients or between client-server, and if they need to be they can simply be put in a global variable and publicvariabled. In opposite (maybe) I think it is important to keep the distincion between clients, so that it is clear to the script author what is local and what is not.

 

Circular references are not handled. Users need to avoid them. Parent and child instances should be able to reference each other. Have you tried? It should work because the compiler runs through the code three times. First time it collects types, second time it collects variables, and third time it compiles the code. Do we mean the same with "reference"?

 

And out of curiosity: What is your project? Are you creating something similar to SQX?

Share this post


Link to post
Share on other sites
9 hours ago, engima said:

Regarding pointers passed between clients I have no plan to tackle that.

 

It's a trivial exercise.  Place all instances into an array, assigning a unique index to each instance.  Place that index at the beginning of each instance.  Now you can create a Pointer which is an index.  The index can be converted into an instance and vice-versa.  The index can be passed over a wire or used as a reference from a child to a parent so that ARMA's recursive arrays are avoided.

 

Because developers work with multiple types, the Pointer should also include the index of the class so you can go to the right table of instances.

 

That takes us back to [type-index, instance-index] pairs as the Pointer implementation.

 

9 hours ago, engima said:

Circular references are not handled. Users need to avoid them.

 

The inability to have circular references would cripple pretty much any design I'd ever think up.  I'm quite surprised that anyone would suggest such a thing.  Doubly-linked-lists, circularly-linked-lists, and parent-child are three trivial examples that spring to mind.  At a broader system design level, I don't worry about whether two objects have indirect references to each other because I don't care.  If I've designed my components correctly, I won't have problems.  I want that rope and I work diligently not to hang myself with it - just as I do with every other rope in my kit.

 

9 hours ago, engima said:

Parent and child instances should be able to reference each other. Have you tried? It should work because the compiler runs through the code three times. First time it collects types, second time it collects variables, and third time it compiles the code. Do we mean the same with "reference"?

 

I have not tried with TypeSqf, but the source of the problem lies with ARMA.  If two arrays reference each other (or if there is an indirect connection between them), ARMA generates an error regardless of how the SQF code came into being.  I wouldn't have started down this road if I hadn't run into the problem in my own stuff.  I implemented my own pointer mechanism to work around it, and that's what I'm encouraging you to tackle.

 

We're talking about the same basic thing, where Type A references Type B which has a back reference to Type A.  But I'm not concerned with resolving names at compile time like you are because I don't have a compile time, just a run time.  Like the rest of my script, object references aren't typed, and that's why I'd really like to go with TypeSqf.  But if you don't implement a basic Pointer mechanism, then I'll have to do it myself.

 

I guess that if I had a Type A for my instances, I'd create a Type A_Pointer to represent a pointer to that class so I keep type safe with my pointer references.  Type A would have an index on it, and Type A_Pointer would hold the index of any instance that it represented.  Then I'd create a Dereference method on A_Pointer to get back the original instance.  It'd work, but I'd be happier if I didn't have to keep creating a pointer class for each instance class.

 

9 hours ago, engima said:

And out of curiosity: What is your project? Are you creating something similar to SQX?

 

No, nothing compile time.  My actual project is a multiplayer mission system that is entirely script-based.  It was getting incredibly-unwieldy as raw scripts, so I fell back on macros for some object-oriented support.  They're not pretty, but they get the job done.  Here's an example of what I have to type right now:

 

OO_BEGIN_SUBCLASS(Class,Parent);

    OO_OVERRIDE_METHOD(Class,Parent,Method,method);

    OO_DEFINE_METHOD(Class,Method,method);

    OO_DEFINE_PROPERTY(Class,Property,"type",default);

OO_END_SUBCLASS(Class);

 

Here's getting and setting a property:

 

private _property = OO_GET(_instance,Class,Property);

OO_SET(_instance,Class,Property,_property);

 

Here's calling a method:

 

[_parameter] call OO_METHOD(_instance,Class,Method);

 

Ugly, but effective.  It all ends up being arrays, of course, but there's runtime overhead that I'd love to discard.

 

On the upside, because I control the macros, I can instrument them to put stuff into the report file and to check anything I'm interested in.  Right now, my debugging relies heavily on seeing an indented list of OO_METHOD and OO_SET calls in the rpt file.  It would be nice if you provided debugging hooks for everything (if you don't already).  Or at least some standard options to kick out trace information per class or some such thing.  My apologies for not looking deeper into TypeSqf.  I've got my hands full with my own project.

Share this post


Link to post
Share on other sites

I just looked at the code you're creating and I see that you're relying exclusively on naming conventions, leading to a need to create constructs such as the following (on an interface call):

    ([_object, [_pos]] call compile ("_this call cl_" + ((_object select 0) select 0) + "_TeleportToPos")); };

That's taken from the interface example in your documentation (which is very clear and concise, by the way, thank you).  You offer a warning about the use of interfaces in high-performance situations as a result, and I can see why interfaces warrant a warning.

 

If you rely on numbers instead of strings, you can just create some global arrays and do three array lookups to call the right method.  You'd be creating vtables for your interfaces.  The same could be done with classes and you're all set to implement subclasses (single inheritance only, please).  Class numbers would be assigned at runtime on a first-come-first-served basis.

 

The lookups would be:

 

1. Get the class index out of the instance

2. Get the class vtable out of the interface table (accessed via a global name)

3. Get the method out of the class vtable

 

In the above example, that would result in the code

([_object, [_pos]] call (Units_ISoldier_VTables select (_object select 0) select 0)

That should perform nicely.

 

I like the use of strings because it makes debugging much more intuitive, but having numbers and lookup tables makes things run faster.  Having both at debug time would certainly provide the best of both worlds.

 

Lastly, I think it's awesome that you chose to implement interfaces.

Share this post


Link to post
Share on other sites

JB47394, thanks for great feedback! I which I'd know who you were from the start of the project. I'll send you a PM.

Share this post


Link to post
Share on other sites

New video: TypeSqf Features Part 4 - The CPack Console

 

This video explains how to handle CPacks in a mission using the TypeSqf editor and its CPack Console. I show how to

  • install a CPack
  • update a CPack
  • remove a CPack
  • list CPacks and check for CPack updates.

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Wow, read through this entire thread.

First Enigma, great work all the way!

 

I am going to start transitioning over to this typeSqf tool today.

I have used notepad++ for 3 years now and am very interested to see how fast this can make my development

 

Thanks again

DirtySanchez

  • Like 1

Share this post


Link to post
Share on other sites

New version released.

 

Version 0.58

-Project file is now saved automatically when starting a new project or opening an existing mission.

-Added video "TypeSqf Features Part 4 - The CPack Console".

-Fixed: No code completion on lines with the alternative variable declaration syntax.

-SQX: Fixed: Compiled files (.sqx.sqf) not removed when a CPack is removed.

-SQX: Analyzer improvements.

-SQX: Fixed: Compiler sometimes not starting.

  • Like 1

Share this post


Link to post
Share on other sites

@engima

Hey bud, I am really liking your creation so far and would like to make a request.

Can you create a way that your program will recognize the "description.ext" file in the mission.
I dont think we need to include anything special for the settings but the important part here are the includes and the classes defined.
I think the added feature would allow an easy way to include all of that information that might be very important to some mission creators that use specialized RscTitles, CfgRemoteExec additions and much, much more.

The reasoning behind my request is to be able to use just TypeSQF during my project and not have to also have notepad++ with the description.ext and any #included files.
Thanks in advance for any consideration you give this request :f:

Share this post


Link to post
Share on other sites

Sure! That sounds like a good idea.

 

But please also give me an example of where the extracted classes can be used. Would it be for auto completion in a script command? I mean: why do you use Notepad++ today, and where goes the information? I have not personally experienced the need yet...

  • Like 1

Share this post


Link to post
Share on other sites

Wow!... mind has been blown!! I can't wait to give this a go, what an awesome looking editor, that cpack feature... I mean, wtf lol... Jesus :)

Share this post


Link to post
Share on other sites

After some thought yesterday, the idea would be very similar to how you have your current setup.
On the list to the left, instead of a folder name, we can use the description.ext and then instead of the filenames it would be the individual classes.

The configs associated with the description.ext are very useful for mission creators and mod creators that are expecting their users to modify the setup.
class CfgEpochClient{
  AnyInfo = "whatever_is_needed";
  Loadout[] = { "uniform","vest","etc","etc"};
};

 

These can be called from the functions using for example:
_config = getArray(missionConfigFile >> "CfgEpochClient" >> "Loadout");

Having this special description.ext on the left list with each class listed below it would be nice.

We also have to take in consideration that many people use the description.ext to #include other .cpp and .hpp files.
These at times will also have class Cfg's in them that arma will see as being in the missionConfigFile.

Honestly thank you for approaching this request bud 


EDIT: Also the reasons behind this would be for ease. Ease in editing, accessing the information and creating new classes without the need for anything else.
This would need the description.ext compiled so the includes can be identified by your program and placed appropriately.
When we click onto any of the defined classes in the left list(child of desciption.ext) we should get the class itself in the editor OR place the cursor on the appropriate line.
I know this can seem confusing and maybe might not be the approach you take, but I do look forward to more. THANKS AGAIN MAN GREAT WORK!

  • Like 1

Share this post


Link to post
Share on other sites

I discovered your software recently.
I really love it and I think I'm going to resume scripting with sqf.

Thanks for your work, encouragement and keep it up!


 

Share this post


Link to post
Share on other sites

New version!

 

Version 0.59

-Added all script commands in Arma 3 version 1.76.

-It is now possible for CPack authors to add a line to the top of description.ext.

-Fixed: Crasch if the CPack installer tries to write to a file that is open by another process.

-Fixed: Stability issues.

-SQX: Analyzer improvements

  • Like 1

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×