MPUZ Revolution development topic, basic engine test

reverse-lookup table; ie the rlt's index numbers are actually existing objects' sysid values, and it maps them to that object's table index in the main object table

i'm going to risk sounding stupid and say it's similar in concept to a pointer

since i need to look up sysids a lot and would rather not constantly loop through the object table to get them, yeah

it can be either, in this case it's a number

type() is your friend

also it's "destination" because there's a few different values you can reference to affect a specific object or a group of them

This post has been edited by Xgoff on Dec 13 2008, 05:11 PM

or i guess if this makes it more clear

oh joy it's time to work on a new level format now :(

but i did get the gravity/collisions module more or less finished so that's good at least

This post has been edited by Xgoff on Dec 15 2008, 10:26 PM

What horrible things are you changing now

remember when you said it wasn't modular enough

yeah well i'm making it so 'modular' about 90% of it's going to be table dumps

I don't remember saying because I don't remember seeing.

i was *****ing about how annoying it'd be to rewrite my more-or-less hardcoded level data design import/export code and you mentioned that

oh hey someone just released an extension that basically replaces sprex (which has been in beta for like 10 months)... well, once this extension's collision and scaling bugs are fixed, unless i somehow ended up with a borked one

this begs the question (again) of how i should implement object images: separate images or tilesets?

originally it was going to be separate but now that tilesets are an option I DON'T KNOW :D

EDIT: actually i might implement both somehow, but the images are accessed differently depending on the method you use so (separate images -> image names; tiles sets -> tile ID number)

This post has been edited by Xgoff on Dec 18 2008, 03:51 PM

yeah it was a rather great christmas gift!

**** guys how am i going to do object-object collisions efficiently :(

i mean they're only like 99% of the gameplay

oh well once i figure that out i might post a really small engine test* or something

*unless lua+ blows up on you which i can't do anything about

i'm bored so that means it's time to script something i can't even test yet



could probably be simplified somewhat but oh well

why have the me.prop1 a string and not a value. I mean that'd make it easier than having to deal with typos and whatnot. So instead of me.prop1 == "one-time" make it me.prop1 == 0 (or something).

because i don't like using numbers for stuff like that

but oh well



see what i did there

This post has been edited by Xgoff on Dec 20 2008, 09:56 AM

yay

It'd be sweet if I actually understood something. Oh well.

Hope you'll get the game out before 2050.

it's not that hard

i'm doing the hard part lol

xgoff can use metatables

uh oh!

in other news, this means i have to tear apart good chunks of the engine (again⁸) so i can actually implement mt's in more than just the event calling... that and i still have to implement object selection (don't worry it doesn't work like MMF's) which is going to require rewriting a lot more stuff

This post has been edited by Xgoff on Jan 1 2009, 11:01 AM

it's time for another giant ****ing bump with info you don't care about!:

• as you've come to expect from me, i've probably rewritten the engine at least 3 times since the last post THEREFORE
  
• the engine actually treats objects as objects instead of numbers that happen to have more data associated with them, so now when you want to actually access a passed object in an event you don't have to do ugly **** like 'objects[objectrl[passed_obj.sysid]].whatever' to get their variables like you would had i released the engine earlier C:
  
  this also means that code in my sigbar doesn't look like that anymore... fortunately
  
• implemented setter methods because those are the only way to ensure objects have any other relevant data associated with a given variable set as well... such as bounding box coordinates which are sometimes important. USE THEM. i'm still on the fence about whether i'd need to implement getter methods or not. probably not
  
• speaking of methods, objects actually use them so they're compatible with a certain set of keywords: single object references me, other, player, null, current, and multiple object set selected (which performs that method on all the selected objects, obviously)
  
• object selection is now actually possible to implement... it'll just be really ****ing ugly to use though because i can't really bull**** a nicer syntax for it. but you might like it if select("function", function () return current.alpha < 255 end) turns you on. and that's just for SELECTING objects; performing the actions isn't going to be any prettier. i never used lua's 'select' function anyway
  
• object plugins are rewritten to be event tables instead of functions; figured i would've learned from doing the same with objects a while ago but apparently not. anyway they can be attached, detached, activated, and deactivated from individual instances which can be useful i guess
  
• objects can be loosely "grouped" into whatever and however many group names you want (or the "official" ones); oh and of course you can add them to or remove them from these groups at runtime (can't really STOP you from doing it). collision tests less of a pain in ass when you can check by group instead of by 30 object names. it was also trivial to implement so SCORE о/

also there may be a chance i'll be able to get a really ugly, broken, and basic engine test up in a couple weeks or sooner since i can do object-object collisions without ugly hacks now THX RII ♥

in any case it won't be impressive but it'll at least show i'm not incompetent :>

This post has been edited by Xgoff on May 20 2009, 02:20 PM

how in gods name did you do the grouping

uh...

object.group[groupname] = true