|
|
Re: my 1st plugin: eLL alpha 0.01
[Re: gamespider]
#70037
10/05/06 08:30
10/05/06 08:30
|
Joined: Dec 2005
Posts: 478
India
msl_manni
Senior Member
|
Senior Member
Joined: Dec 2005
Posts: 478
India
|
Hi testdummy, I think I have some use for the ell.dll for a game I am creating  . Could you give me a link for the latest bug free download. BTW I am using 6.4ver of 3dgs  . Thanks in advance, MSL.
My Specialities Limited.
|
|
|
Re: my 1st plugin: eLL alpha 0.01
[Re: msl_manni]
#70038
10/05/06 14:57
10/05/06 14:57
|
Joined: Sep 2002
Posts: 8,177
Netherlands
PHeMoX
Senior Expert
|
Senior Expert
Joined: Sep 2002
Posts: 8,177
Netherlands
|
Hey, that actually comes in very handy Testdummy! Thanks,
Edit: only noticed this thread like now hehehe,
Cheers
Last edited by PHeMoX; 10/05/06 14:59.
|
|
|
Re: my 1st plugin: eLL alpha 0.01
[Re: PHeMoX]
#70039
10/05/06 15:07
10/05/06 15:07
|
Anonymous
Unregistered
|
Anonymous
Unregistered
|
I haven't got the source code for this any more (computer died and took most of my stuff with it), but could it be modified to store just simple numbers instead of entity pointers? I have a need for dynamically-allocated arrays of numbers for something I'm working on.
|
|
|
eLL: entity linked lists and arrays plugin
[Re: ]
#70040
10/06/06 04:37
10/06/06 04:37
|
Joined: Oct 2004
Posts: 1,655
testDummy
OP
Serious User
|
OP
Serious User
Joined: Oct 2004
Posts: 1,655
|
Right now I don't really have the time or incentive to actively develop this simple plugin (, but I may return to it sometime in the near future). However, I will make it available again for those that may have a use for it. eLL-060426-6.3 (for 3DGS 6.3)eLL-060426-6.4 (for 3DGS 6.4)The first string of numbers, which might be considered the 'version', indicates the date last modified (year month day). The second string of numbers indicates the version of the 3DGS SDK used to compile the plugin. It seems the eLL version compiled with the 6.3 version of the 3DGS SDK does not work with 3DGS version 6.40.5 (which isn't surprising), so obviously the eLL version compiled with 6.4 SDK should be used with 3DGS version 6.40.5. Of course, if you are using 3DGS version 6.31.4, you would use the eLL version compiled with the 6.3 SDK. As indicated by the date-modified strings, I haven't made any serious changes since the date of 04/26/06 (06.04.26). I simply recompiled the old version with the 6.4 SDK and reposted both versions. Check file eLL-comments.txt to view the comments from the interface functions which are also found in the source. (The comments for the ea instructions were never added to eLL-comments.txt in the 6.3 distro.) The eLL plugin contains extremely simple implementations of an array of entity linked lists and an array of dynamic entity arrays. The plugin is freeware and open source (the source is included, but for the most part, the SDKs, compilers, compiler dependent project files, intermediate files, etc. are not). Quote:
Could you give me a link for the latest bug free download.
Quoted msl_manni.
Generally, it is assumed that software contains bugs, and that in a strict sense, truly bug-free software may not exist. (But am I applying the attitude of a defeatist here?)
While obviously, I wouldn't intentionally leave bugs in without good reasons, I don't offer any guarantees or warrantees.
Quote:
I haven't got the source code for this any more (computer died and took most of my stuff with it), but could it be modified to store just simple numbers instead of entity pointers? I have a need for dynamically-allocated arrays of numbers for something I'm working on.
Quoted Gorthaur.
I can't seem to interpret that correctly. Can you elaborate?
From what you've written it may seem that you might want to replace most occurrences of entity pointers in the implementation with variables or numbers?
Why? (I'm not going to type in an educated guess for that 'why'.)
Maybe instead, you just want dynamic arrays of variables and you don't actually want to replace parts of the 'implementation'. If this is the case, you might use the ea implementation as an example, but it isn't a very 'good' example for an implementation of an array of dynamic arrays of variables.
|
|
|
Re: eLL: entity linked lists and arrays plugin
[Re: lyingmime]
#70042
10/06/06 13:01
10/06/06 13:01
|
Joined: Dec 2005
Posts: 478
India
msl_manni
Senior Member
|
Senior Member
Joined: Dec 2005
Posts: 478
India
|
Before I even start to explore your dll, I have a serious question. As dll is creating the linked lists in memory, and its in a seperate threads. What provisions are there for a game save and game load. If in the middle of a game, a player saves his game and some time later he loads from the previous save. The entities table will be out of sync, and what if the player loads a already saved game. The pointers would be totally irrelevant. Please explain wether I am right or wrong in my apprehensions.
My Specialities Limited.
|
|
|
Re: eLL: entity linked lists and arrays plugin
[Re: msl_manni]
#70043
10/06/06 20:33
10/06/06 20:33
|
Joined: Oct 2004
Posts: 1,655
testDummy
OP
Serious User
|
OP
Serious User
Joined: Oct 2004
Posts: 1,655
|
Thank you. I intended to indicate that currently there is no direct support for the game_load and game_save instructions, but I had forgotten.
The eLL plugin:
*again, is extremely simple freeware
*again, is my first 3DGS plugin (don't expect much)
*again, is open source and you are encouraged to modify it
*again, is not being actively developed at this time (but I may return to it in the near future)
*probably should not be considered a 'commercial grade' solution
*in it's current state, might be completely useless without direct game_load and game_save instruction support
Potentially, the more people that use it the more support I might have to provide, so I am not necessarily encouraging (heavy) 'use'.
Although improbable, I suppose hypothetically, if the game load and save processes can be controlled, assuming there is enough information pertaining to the game load and save processes, it might be possible to 'serialize' the handles and resurrect the pointers. (There is a slim chance it could be done in C-Script).
|
|
|
Re: eLL: entity linked lists and arrays plugin
[Re: testDummy]
#70044
10/07/06 08:08
10/07/06 08:08
|
Anonymous
Unregistered
|
Anonymous
Unregistered
|
It should be possible to transfer all the entities' handles to a bunch of arrays or something similar? Then when you load, reinstate all the eLLs and handles to do with them. Downsides: very lengthy operation, tricky to code, probably increase the save/load time by a lot, etc. Plus, it would limit the size of the eLLs to be saved to the size of the arrays you had to save them, defeating the purpose of having eLLs in the first place... testDummy: What I meant was pretty much what you have here, but instead of storing entities, it stores variables. I was going to have a crack at modifying the source myself, but the first line lost me  I'm not a C++ programmer Quote:
Why? (I'm not going to type in an educated guess for that 'why'.)
I'm trying to create a neural network with 3DGS, and I want the network to store the values of its nodes and weights internally - rather than using a fixed-size global array. For this I need an array bigger than 3 vars long. If I instead give it a pointer to a dynamically allocated array, my problem is solved.
|
|
|
Re: eLL: entity linked lists and arrays plugin
[Re: PHeMoX]
#70046
10/09/06 00:02
10/09/06 00:02
|
Joined: Oct 2004
Posts: 1,655
testDummy
OP
Serious User
|
OP
Serious User
Joined: Oct 2004
Posts: 1,655
|
Quote:
It should be possible to transfer all the entities' handles to a bunch of arrays or something similar?
Quoted Gorthaur.
If I were trying to enable support for the game_load and game_save instructions, I probably wouldn't choose 'array final destinations' for the handle values, instead, assuming I can access the 'true handle' values, I would probably try to write the handle values to file.
Quote:
Then when you load, reinstate all the eLLs and handles to do with them. Downsides:
Quote:
very lengthy operation,
I don't know what is really meant by 'very lengthy operation' here, but for some interpretations, generally, it wouldn't seem to be to me.
Quote:
tricky to code,
Assuming the 'true handle values' can be accessed, simply dumping the handle values to file, retrieving them again and recreating the lists might almost be trival, but it probably isn't practical to do so from C-Script because there may be no access to the 'true handle values'.
User proofing might be 'tricky' or impossible.
Without some knowledge pertaining to the behavior of the game_load and game_save instructions and how the user might use those instructions and still 'maintain sync', the almost trival parts might be irrelevant and real working functionality might be damned.
Quote:
probably increase the save/load time by a lot, etc.
Maybe not.
Quote:
testDummy: What I meant was pretty much what you have here, but instead of storing entities, it stores variables. I was going to have a crack at modifying the source myself, but the first line lost me I'm not a C++ programmer
I'm trying to create a neural network with 3DGS, and I want the network to store the values of its nodes and weights internally - rather than using a fixed-size global array. For this I need an array bigger than 3 vars long. If I instead give it a pointer to a dynamically allocated array, my problem is solved.
Quoted Gorthaur.
(In such cases, you would probably want to reuse memory and not grab large, temporary chunks and needlessly throw those large chunks away often.)
If I were going to write something for that or for similar things, I might write a separate plugin. Although it's use might be relatively awkward, writing a plugin that just handles dynamic arrays of variables somewhat, probably wouldn't prove to be all that difficult. Maybe I'll try to write such a plugin in the near future (certainly I would trade such a plugin for a full and complete understanding of neural networks), but, in the meantime, I might suggest that you make a request thread in the "User Requests" thread category. Certainly, such a plugin might be 'easy work' for many.
Quote:
Testdummy, I'm not sure wether or not there were any significant changes concerning plug-in 'support' in the most recently released update, however aware of the possibility that this dll may not work with A6.50.2 would you be so kind as to recompile this dll so it's functional with A6.50.2? That would be cool,
Quoted PHeMoX.
I'm sorry, but I am under the impression that 3DGS version 6.50.2 is not, in fact, an official update, but is instead a (very buggy?) public beta and, at this time, I do not intend to work with that version (currently waiting for more stability and permanence) and I do not intend to compile plugins for something so mutable. However, for the most part, I do intend to compile plugins for future official updates. In this instance, I do not necessarily want to be 'unhelpful', so I may very well provide a sample testing device (set of scripts, level, etc.) so that eLL functionality can be more easily tested by others, so that it is not all that difficult for users to quicky determine whether or not the plugin works for them, with the 3DGS version they are using.
edit: At this time, I'm not going to download and install the complete 3DGS (public beta?) version 6.50.2 just to recompile the eLL plugin. However, assuming that the (6.50 SDK?) has changed , you may provide a link to download the SDK only (assuming that there are no license violations in doing so), and I may recompile the eLL plugin using that SDK, but if I do so, it will not be tested with version 6.50.2 of the engine by me.
|
|
|
|
